home *** CD-ROM | disk | FTP | other *** search
/ Celestin Apprentice 5 / Apprentice-Release5.iso / Information / CSMP Digest / volume 3 / csmp-digest-v3-027 < prev    next >
Text File  |  1995-12-31  |  81KB  |  2,342 lines

  1. Received-Date: Sun, 15 May 1994 21:57:15 +0200
  2. From: pottier@clipper.ens.fr (Francois Pottier)
  3. Subject: csmp-digest-v3-027
  4. To: csmp-digest@ens.fr
  5. Date: Sun, 15 May 94 21:57:08 MET DST
  6. X-Mailer: ELM [version 2.3 PL11]
  7. Errors-To: listman@ens.fr
  8. Reply-To: pottier@clipper.ens.fr
  9. X-Sequence: 30
  10.  
  11. C.S.M.P. Digest             Sun, 15 May 94       Volume 3 : Issue 27
  12.  
  13. Today's Topics:
  14.  
  15.         Determining if user has a CD ROM drive
  16.         Lex and Yacc for Mac Programmers
  17.         PowerMac FP performance - interesting results????
  18.         Saving the floating Point Registers
  19.         The NewWindow case
  20.         Truetype font format specification: No longer available from Apple ?!
  21.  
  22.  
  23.  
  24. The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
  25. (pottier@clipper.ens.fr).
  26.  
  27. The digest is a collection of article threads from the internet newsgroup
  28. comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
  29. regularly and want an archive of the discussions.  If you don't know what a
  30. newsgroup is, you probably don't have access to it.  Ask your systems
  31. administrator(s) for details.  If you don't have access to news, you may
  32. still be able to post messages to the group by using a mail server like
  33. anon.penet.fi (mail help@anon.penet.fi for more information).
  34.  
  35. Each issue of the digest contains one or more sets of articles (called
  36. threads), with each set corresponding to a 'discussion' of a particular
  37. subject.  The articles are not edited; all articles included in this digest
  38. are in their original posted form (as received by our news server at
  39. nef.ens.fr).  Article threads are not added to the digest until the last
  40. article added to the thread is at least two weeks old (this is to ensure that
  41. the thread is dead before adding it to the digest).  Article threads that
  42. consist of only one message are generally not included in the digest.
  43.  
  44. The digest is officially distributed by two means, by email and ftp.
  45.  
  46. If you want to receive the digest by mail, send email to listserv@ens.fr
  47. with no subject and one of the following commands as body:
  48.     help                        Sends you a summary of commands
  49.     subscribe csmp-digest Your Name    Adds you to the mailing list
  50.     signoff csmp-digest            Removes you from the list
  51. Once you have subscribed, you will automatically receive each new
  52. issue as it is created.
  53.  
  54. The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
  55. Questions related to the ftp site should be directed to
  56. scott.silver@dartmouth.edu. Currently no previous volumes of the CSMP
  57. digest are available there.
  58.  
  59. Also, the digests are available to WAIS users as comp.sys.mac.programmer.src.
  60.  
  61.  
  62. -------------------------------------------------------
  63.  
  64. >From mkelly@cs.uoregon.edu (Michael A. Kelly)
  65. Subject: Determining if user has a CD ROM drive
  66. Date: 25 Apr 1994 15:18:08 -0700
  67. Organization: High Risk Ventures
  68.  
  69.  
  70. Hey,
  71.  
  72. Is there any way to determine (through software) if a given machine has a
  73. CD ROM drive attached to it?  Do I just have to look for an unwritable disk
  74. larger than 500MB (and wouldn't that only show up if there's a CD mounted)?
  75. Is there any other way?
  76.  
  77. Thanks,
  78.  
  79. Mike.
  80. -- 
  81. _____________________________________________________________________________
  82. Michael A. Kelly                                                President/CEO
  83. mkelly@cs.uoregon.edu                                      High Risk Ventures
  84. _____________________________________________________________________________
  85.  
  86. +++++++++++++++++++++++++++
  87.  
  88. >From mxmora@unix.sri.com (Matt Mora)
  89. Date: 25 Apr 1994 16:55:17 -0700
  90. Organization: SRI International, Menlo Park, CA
  91.  
  92. In article <2phfj0$95h@majestix.cs.uoregon.edu> mkelly@cs.uoregon.edu (Michael A. Kelly) writes:
  93. >
  94. >Hey,
  95. >
  96. >Is there any way to determine (through software) if a given machine has a
  97. >CD ROM drive attached to it?  Do I just have to look for an unwritable disk
  98. >larger than 500MB (and wouldn't that only show up if there's a CD mounted)?
  99. >Is there any other way?
  100.  
  101.  
  102. Sure,
  103.  
  104. Here you go:
  105.  
  106. //------------------------------------------------------------
  107.   pascal  OSErr OpenCD(Byte CDDrive, short *ioRefNum) {
  108. //------------------------------------------------------------
  109.  
  110.   auto  OSErr     osErr;
  111.   auto  short     ioRefNumTemp,
  112.                   CDDriveCount,
  113.                   SCSIID;
  114.   auto  WhoIsThereRec *pb;
  115.  
  116.   pb = (WhoIsThereRec *) NewPtrClear(sizeof (*pb));
  117.   osErr = MemError();
  118.   if (0 != pb && noErr == osErr) {
  119.     osErr = OpenDriver("\p.AppleCD", &ioRefNumTemp);
  120.     if (noErr == osErr) {
  121.       (*pb).ioRefNum    = ioRefNumTemp;
  122.       (*pb).csCode    = csWhoIsThere;
  123.       osErr = PBStatus((ParmBlkPtr)pb, false);
  124.       if (noErr == osErr) {
  125.         CDDriveCount = 0;
  126.         for (SCSIID = 0; SCSIID < 7; ++SCSIID) {
  127.           if (BitTst(&(*pb).csParam.SCSIMask, 7 - SCSIID)) {
  128.             ++CDDriveCount;
  129.             if (CDDrive == CDDriveCount) {
  130.               *ioRefNum = -(32 + SCSIID) - 1;
  131.               DisposPtr((Ptr) pb);
  132.               return noErr;
  133.             }
  134.           }
  135.         }
  136.         osErr = paramErr;
  137.       }
  138.     }
  139.     DisposPtr((Ptr) pb);
  140.   }
  141.   return osErr;
  142. }
  143.  
  144.  
  145. I didn't write it it came from:
  146.  
  147. // imWare
  148. // Wednesday, February 14, 1990
  149. // James Beninghaus
  150.  
  151.  
  152. Xavier
  153.  
  154.  
  155. -- 
  156. ___________________________________________________________
  157. Matthew Xavier Mora                       Matt_Mora@sri.com
  158. SRI International                       mxmora@unix.sri.com
  159. 333 Ravenswood Ave                    Menlo Park, CA. 94025
  160.  
  161. +++++++++++++++++++++++++++
  162.  
  163. >From mclow@csusm.edu (Marshall Clow)
  164. Date: 26 Apr 1994 00:36:17 GMT
  165. Organization: (none)
  166.  
  167. Matt Mora (mxmora@unix.sri.com) wrote:
  168. >In article <2phfj0$95h@majestix.cs.uoregon.edu> mkelly@cs.uoregon.edu
  169. > (Michael A. Kelly) writes:
  170. >>
  171. >>Hey,
  172. >>
  173. >>Is there any way to determine (through software) if a given machine has a
  174. >>CD ROM drive attached to it?  Do I just have to look for an unwritable disk
  175. >>larger than 500MB (and wouldn't that only show up if there's a CD mounted)?
  176. >>Is there any other way?
  177.  
  178.  
  179. >Sure,
  180.  
  181. >Here you go:
  182.  
  183. [ code deleted ]
  184.  
  185. Matt,
  186.     Pardon me if I missed something, but the code that you posted
  187. only works if the Apple CD-ROM drivers are installed. What if the CD-ROM
  188. that the user has uses it's own, custom driver?
  189.  
  190. Perhaps if the original poster could provide some more information
  191. about what he was trying to accomplish, someone could suggest a solution.
  192.  
  193. -- Marshall
  194.  
  195. Marshall Clow
  196. I are an Engineer!
  197. Aladdin Systems
  198. mclow@san_marcos.csusm.edu
  199.  
  200.  
  201. +++++++++++++++++++++++++++
  202.  
  203. >From mkelly@cs.uoregon.edu (Michael A. Kelly)
  204. Date: 26 Apr 1994 00:08:21 -0700
  205. Organization: High Risk Ventures
  206.  
  207. In article <2phnm1$dqm@coyote.csusm.edu>,
  208. Marshall Clow <mclow@csusm.edu> wrote:
  209. >    Pardon me if I missed something, but the code that you posted
  210. >only works if the Apple CD-ROM drivers are installed. What if the CD-ROM
  211. >that the user has uses it's own, custom driver?
  212. >
  213. >Perhaps if the original poster could provide some more information
  214. >about what he was trying to accomplish, someone could suggest a solution.
  215.  
  216. I simply want to know if there is a CD ROM drive attached to the machine.
  217. I am not going to do anything with that information, besides take note of
  218. it.  It will become part of a 'system code' that the user can give to a
  219. tech support person when there is trouble - rather than the tech support
  220. person having to ask the user for each tidbit of information, they just
  221. ask for this code, which immediately gives them all the basic information
  222. they need about the user's machine.
  223.  
  224. Of course, whether or not the user has a CD ROM drive is pretty unimportant
  225. for tech support (if it was important it would probably be given).  This
  226. system code is also used to give us some statistics about the number of
  227. CD ROM drives in our customer base.
  228.  
  229. All of this is irrelevant to the question at hand, though.
  230.  
  231. Mike.
  232. -- 
  233. _____________________________________________________________________________
  234. Michael A. Kelly                                                President/CEO
  235. mkelly@cs.uoregon.edu                                      High Risk Ventures
  236. _____________________________________________________________________________
  237.  
  238. +++++++++++++++++++++++++++
  239.  
  240. >From d88-jwa@dront.nada.kth.se (Jon Wdtte)
  241. Date: 26 Apr 1994 08:10:11 GMT
  242. Organization: The Royal Institute of Technology
  243.  
  244. In <2phfj0$95h@majestix.cs.uoregon.edu> mkelly@cs.uoregon.edu (Michael A. Kelly) writes:
  245.  
  246. >Is there any way to determine (through software) if a given machine has a
  247. >CD ROM drive attached to it?  Do I just have to look for an unwritable disk
  248.  
  249. Use the SCSI manager to examine all SCSI devices and look for a CD-ROM
  250. type device.
  251.  
  252. But why? Most users can be trusted to look around their computer, see
  253. "hey, here's a CD-ROM" and check the appropriate check box; that's
  254. several magnitudes safer than any automatic check.
  255.  
  256. And if you're gathering statistics behind the users back, don't.
  257. Remember that Prograph was close to being publicly flogged for the
  258. "Exploding Pink Poodles" stuff, which was something their mastering
  259. company put there.
  260. -- 
  261.  -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe --
  262.  "Don't Deal with a Dragon."
  263.  
  264. +++++++++++++++++++++++++++
  265.  
  266. >From d88-jwa@dront.nada.kth.se (Jon Wdtte)
  267. Date: 26 Apr 1994 08:11:07 GMT
  268. Organization: The Royal Institute of Technology
  269.  
  270. In <2phl95$i30@unix.sri.com> mxmora@unix.sri.com (Matt Mora) writes:
  271.  
  272. >    osErr = OpenDriver("\p.AppleCD", &ioRefNumTemp);
  273.  
  274. There are other CD-ROM drivers than Apple's CD driver, like
  275. NECs or Toshibas. This solution loses.
  276. -- 
  277.  -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe --
  278.  "Don't Deal with a Dragon."
  279.  
  280. +++++++++++++++++++++++++++
  281.  
  282. >From mxmora@unix.sri.com (Matt Mora)
  283. Date: 26 Apr 1994 10:47:41 -0700
  284. Organization: SRI International, Menlo Park, CA
  285.  
  286. In article <2phnm1$dqm@coyote.csusm.edu> mclow@csusm.edu (Marshall Clow) writes:
  287.  
  288. >Matt,
  289. >    Pardon me if I missed something, but the code that you posted
  290. >only works if the Apple CD-ROM drivers are installed. What if the CD-ROM
  291. >that the user has uses it's own, custom driver?
  292.  
  293.  
  294. Picky, Picky.  Test for non-apple drivers is left as an exercise for the 
  295. reader. :-)
  296.  
  297. I thought that he might want to do something usefull like distribute
  298. his games on CDrom chock full of 32 bit sounds and graphics using driver
  299. calls for access.
  300.  
  301.  
  302.  
  303. Xavier
  304.  
  305.  
  306.  
  307. -- 
  308. ___________________________________________________________
  309. Matthew Xavier Mora                       Matt_Mora@sri.com
  310. SRI International                       mxmora@unix.sri.com
  311. 333 Ravenswood Ave                    Menlo Park, CA. 94025
  312.  
  313. +++++++++++++++++++++++++++
  314.  
  315. >From mkelly@cs.uoregon.edu (Michael A. Kelly)
  316. Date: 26 Apr 1994 11:46:35 -0700
  317. Organization: High Risk Ventures
  318.  
  319. In article <2pii93$hls@news.kth.se>,
  320. Jon Wdtte <d88-jwa@dront.nada.kth.se> wrote:
  321. >Use the SCSI manager to examine all SCSI devices and look for a CD-ROM
  322. >type device.
  323.  
  324. How do I do that?  I've been looking at the SCSI Manager in Think Reference,
  325. and I can't figure out how to tell if the device is a CD ROM device.
  326.  
  327. >Remember that Prograph was close to being publicly flogged for the
  328. >"Exploding Pink Poodles" stuff, which was something their mastering
  329. >company put there.
  330.  
  331. I don't remember anything about that - what happened?
  332.  
  333. We have no intention of making the data we gather public in any way - it's
  334. strictly for our own information.  So that someday in the future when we're
  335. thinking that we'd like to make an action CD game, we can look at our
  336. customer base and see what percentage of action game players have a CD drive.
  337. I don't expect the information to be all that useful, or reliable, but it
  338. doesn't hurt to gather it.
  339.  
  340. Mike.
  341. -- 
  342. _____________________________________________________________________________
  343. Michael A. Kelly                                                President/CEO
  344. mkelly@cs.uoregon.edu                                      High Risk Ventures
  345. _____________________________________________________________________________
  346.  
  347. +++++++++++++++++++++++++++
  348.  
  349. >From isis@netcom.com (Mike Cohen)
  350. Date: Tue, 26 Apr 1994 17:40:03 GMT
  351. Organization: ISIS International
  352.  
  353. mxmora@unix.sri.com (Matt Mora) writes:
  354.  
  355. >In article <2phfj0$95h@majestix.cs.uoregon.edu> mkelly@cs.uoregon.edu (Michael A. Kelly) writes:
  356. >>
  357. >>Hey,
  358. >>
  359. >>Is there any way to determine (through software) if a given machine has a
  360. >>CD ROM drive attached to it?  Do I just have to look for an unwritable disk
  361. >>larger than 500MB (and wouldn't that only show up if there's a CD mounted)?
  362. >>Is there any other way?
  363.  
  364.  
  365. >Sure,
  366.  
  367. >Here you go:
  368. (code snippet deleted)
  369. >I didn't write it it came from:
  370.  
  371. >// imWare
  372. >// Wednesday, February 14, 1990
  373. >// James Beninghaus
  374.  
  375. This is the cleanest way (I've done it that way myself for an ISO9660 CD
  376. browser), but it will only work for an Apple or compatible drive.
  377. -- 
  378. Mike Cohen - isis@netcom.com
  379. NewtonMail, eWorld: MikeC / ALink: D6734 / AOL: MikeC20
  380.  
  381. +++++++++++++++++++++++++++
  382.  
  383. >From Phil Smy <psmy@io.org>
  384. Date: 27 Apr 1994 13:50:26 GMT
  385. Organization: Innotech MultiMedia Corp.
  386.  
  387. In article <2piiar$hlt@news.kth.se> Jon W!tte, d88-jwa@dront.nada.kth.se
  388. writes:
  389. >>    osErr = OpenDriver("\p.AppleCD", &ioRefNumTemp);
  390. >
  391. >There are other CD-ROM drivers than Apple's CD driver, like
  392. >NECs or Toshibas. This solution loses.
  393.  
  394. Actually, for some reason, with NEC drivers this does work! They must
  395. register themselves (actually I think all cd drivers do) as ".AppleCD".
  396.  
  397. Phil
  398. ******************************************************************
  399. * Phil Smy                    * Interactive CDRom MultiMedia     *
  400. * Sr. Developer               * #include <stddisclaimer.h>       *
  401. * Innotech MultiMedia Corp.   * Wot Gorilla?                     *
  402. ******************************************************************
  403.  
  404. +++++++++++++++++++++++++++
  405.  
  406. >From sch@unx.sas.com (Steve Holzworth)
  407. Date: Wed, 27 Apr 1994 21:10:12 GMT
  408. Organization: SAS Institute Inc.
  409.  
  410. mkelly@cs.uoregon.edu (Michael A. Kelly) writes:
  411.  
  412. >In article <2pii93$hls@news.kth.se>,
  413. >Jon Wdtte <d88-jwa@dront.nada.kth.se> wrote:
  414. >>Use the SCSI manager to examine all SCSI devices and look for a CD-ROM
  415. >>type device.
  416.  
  417. >How do I do that?  I've been looking at the SCSI Manager in Think Reference,
  418. >and I can't figure out how to tell if the device is a CD ROM device.
  419.  
  420. The SCSI "Inquiry" command returns info about the specified SCSI device,
  421. including a code which says that it is a ROM, WORM, DISK, etc.
  422.  
  423. A peripheral type  5 should be a CD-ROM drive.
  424. --
  425. Steve Holzworth
  426. sch@unx.sas.com                    "Do not attribute to poor spelling
  427. SAS Institute   x6872               That which is actually poor typing..."
  428. SAS/Macintosh Development Team                            - me
  429. Cary, N.C.
  430.  
  431. +++++++++++++++++++++++++++
  432.  
  433. >From mkelly@cs.uoregon.edu (Michael A. Kelly)
  434. Date: 28 Apr 94 08:30:22 GMT
  435. Organization: High Risk Ventures
  436.  
  437. In article <sch.767481012@gargoyle>, Steve Holzworth <sch@unx.sas.com> wrote:
  438. >
  439. >The SCSI "Inquiry" command returns info about the specified SCSI device,
  440. >including a code which says that it is a ROM, WORM, DISK, etc.
  441.  
  442. OK, but the problem is that I don't have the scsi specs, so I don't know
  443. how to send an inquiry command or get the id from whatever it returns....
  444.  
  445. Mike.
  446. -- 
  447. _____________________________________________________________________________
  448. Michael A. Kelly                                                President/CEO
  449. mkelly@cs.uoregon.edu                                      High Risk Ventures
  450. _____________________________________________________________________________
  451.  
  452. +++++++++++++++++++++++++++
  453.  
  454. >From sch@unx.sas.com (Steve Holzworth)
  455. Date: Thu, 28 Apr 1994 22:37:52 GMT
  456. Organization: SAS Institute Inc.
  457.  
  458. mkelly@cs.uoregon.edu (Michael A. Kelly) writes:
  459.  
  460. >In article <sch.767481012@gargoyle>, Steve Holzworth <sch@unx.sas.com> wrote:
  461. >>
  462. >>The SCSI "Inquiry" command returns info about the specified SCSI device,
  463. >>including a code which says that it is a ROM, WORM, DISK, etc.
  464.  
  465. >OK, but the problem is that I don't have the scsi specs, so I don't know
  466. >how to send an inquiry command or get the id from whatever it returns....
  467.  
  468. I hope you have Macintosh documentation on the SCSI Manager, otherwise
  469. the problem becomes too complex, short of me writing you the actual code
  470. to do the Inquiry. Assuming you DO have the SCSI Manager doc, use a
  471. SCSI command block as follows:
  472.  
  473. The SCSI Inquiry command is command code 0x12.
  474. The command block is as follows (conforms to SCSI2 spec):
  475.  
  476.         Bits
  477.      | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
  478. Byte
  479. 0    Inquiry (0x12)
  480. 1    | LogUnit#  |        0          |
  481. 2        0
  482. 3           0
  483. 4    Allocation Length
  484. 5           0
  485.  
  486. LogUnit# is a logical unit at this SCSI ID, and should almost always be
  487. zero (note, this isn't the same as the SCSI ID itself; it's a sub-unit).
  488.  
  489. Allocation Length is the size of the maximum buffer that should be returned
  490. by this command. You only care about the first byte, so try 1. The Macintosh
  491. is good about throwing away excess bytes and resyncing the SCSI handshake.
  492.  
  493. The first byte returned is the device type, as mentioned in the previous
  494. post.
  495.  
  496. --
  497. Steve Holzworth
  498. sch@unx.sas.com                    "Do not attribute to poor spelling
  499. SAS Institute   x6872               That which is actually poor typing..."
  500. SAS/Macintosh Development Team                            - me
  501. Cary, N.C.
  502.  
  503. +++++++++++++++++++++++++++
  504.  
  505. >From tzs@u.washington.edu (Tim Smith)
  506. Date: 1 May 1994 06:32:31 GMT
  507. Organization: University of Washington School of Law, Class of '95
  508.  
  509. Michael A. Kelly <mkelly@cs.uoregon.edu> wrote:
  510. >How do I do that?  I've been looking at the SCSI Manager in Think Reference,
  511. >and I can't figure out how to tell if the device is a CD ROM device.
  512.  
  513. Try this.  The following was written when Think C first came out with
  514. the objected oriented extensions, and was my first attempt to use
  515. them, which is why it goes a bit overboard.  The first two files
  516. below define an object oriented interface to the SCSI manager.
  517. The third file scans the SCSI bus looking for a tape drive.
  518. At the end, I'll tell you where to change it to look for a
  519. CD-ROM drive.
  520.  
  521. - -------- file cscsi.h ----------
  522.  
  523. #ifndef CSCSI_H
  524. #define    CSCSI_H
  525.  
  526. #include    <SCSI.H>
  527.  
  528. typedef enum
  529. {
  530.     dataIn=1, dataOut=2, noData=3
  531. } XferDir;
  532.  
  533. #define    USE_CDB        0x01
  534. #define    USE_BUF        0x02
  535. #define    USE_LEN        0x04
  536. #define    USE_DIR        0x08
  537. #define    USE_ID        0x10
  538.  
  539. #define    CAN_DATA    (USE_CDB|USE_BUF|USE_LEN|USE_DIR|USE_ID)
  540. #define    CAN_NO_DATA    (USE_CDB|USE_DIR|USE_ID)
  541.  
  542. #define    SCSI_NEED_INFO    (-1)
  543. #define    SCSI_OK            (0)
  544.  
  545. class    CSCSIOp
  546. {
  547.     short    targetID;
  548.     char    cdb[12];
  549.     char    cdbLen;
  550.     unsigned char *    dataPtr;
  551.     long    dataLen;
  552.     short    status;
  553.     short    message;
  554.     OSErr    err;
  555.     XferDir    dir;
  556.     long    timeout;
  557.     int        haveInfo;
  558.     long    moved;
  559. public:
  560.             CSCSIOp( void );
  561.             ~CSCSIOp( void );
  562.     void    keep( int what );
  563.     void    setID( short ID );
  564.     void    setCDB( int len, char * cdbPtr );
  565.     void    set6( char a, char b, char c, char d, char e, char f );
  566.     void    set10( char a, char b, char c, char d, char e, char f,
  567.                     char g, char h, char i, char j );
  568.     void    set12( char a, char b, char c, char d, char e, char f,
  569.                     char g, char h, char i, char j, char k, char l );
  570.     void    setLen( long len );
  571.     void    setBuf( void * buf );
  572.     void    setDir( XferDir direction );
  573.     int        execute( void );
  574.     short    getStatus( void );
  575.     short    getMessage( void );
  576.     void    setTimeout( long newTime );
  577.     OSErr    getErr( void );
  578.     long    getMoved( void );
  579. };
  580.  
  581. #endif
  582.  
  583. - ------ file cscsi.cp ------------
  584.  
  585. #include    "CSCSI.h"
  586. #include    <stdio.h>
  587.  
  588. CSCSIOp::CSCSIOp( void )
  589. {
  590.     haveInfo = 0;
  591.     timeout = 60L;
  592. }
  593.  
  594. CSCSIOp::~CSCSIOp( void )
  595. {
  596. }
  597.  
  598. void    CSCSIOp::keep( int what )
  599. {
  600.     haveInfo = what;
  601. }
  602.  
  603. void    CSCSIOp::setID( short ID )
  604. {
  605.     targetID = ID;
  606.     haveInfo |= USE_ID;
  607. }
  608.  
  609. void    CSCSIOp::setCDB( int len, char * cdbPtr )
  610. {
  611.     int        i;
  612.     cdbLen = len;
  613.     for ( i = 0; i < len; i++ )
  614.         cdb[i] = *cdbPtr++;
  615.     haveInfo |= USE_CDB;
  616. }
  617.  
  618. void    CSCSIOp::set6( char a, char b, char c, char d, char e, char f )
  619. {
  620.     cdbLen = 6;
  621.     cdb[0] = a; cdb[1] = b; cdb[2] = c; cdb[3] = d; cdb[4] = e; cdb[5] = f;
  622.     haveInfo |= USE_CDB;
  623. }
  624.  
  625. void    CSCSIOp::set10( char a, char b, char c, char d, char e, char f,
  626.                 char g, char h, char i, char j )
  627. {
  628.     cdbLen = 10;
  629.     cdb[0] = a; cdb[1] = b; cdb[2] = c; cdb[3] = d; cdb[4] = e; cdb[5] = f;
  630.     cdb[6] = g; cdb[7] = h; cdb[8] = i; cdb[9] = j;
  631.     haveInfo |= USE_CDB;
  632. }
  633.  
  634. void    CSCSIOp::set12( char a, char b, char c, char d, char e, char f,
  635.                 char g, char h, char i, char j, char k, char l )
  636. {
  637.     cdbLen = 12;
  638.     cdb[0] = a; cdb[1] = b; cdb[2] = c; cdb[3] = d; cdb[4] = e; cdb[5] = f;
  639.     cdb[6] = g; cdb[7] = h; cdb[8] = i; cdb[9] = j; cdb[10] = k; cdb[11] = l;
  640.     haveInfo |= USE_CDB;
  641. }
  642.  
  643. void    CSCSIOp::setLen( long len )
  644. {
  645.     dataLen = len;
  646.     haveInfo |= USE_LEN;
  647. }
  648.  
  649. void    CSCSIOp::setBuf( void * buf )
  650. {
  651.     dataPtr = (unsigned char *)buf;
  652.     haveInfo |= USE_BUF;
  653. }
  654.  
  655. void    CSCSIOp::setDir( XferDir direction )
  656. {
  657.     dir = direction;
  658.     haveInfo |= USE_DIR;
  659. }
  660.  
  661. int        CSCSIOp::execute( void )
  662. {
  663.     SCSIInstr    xfer[3];
  664.     int            info = haveInfo;
  665.     
  666.     haveInfo = 0;
  667.     
  668.     if ( info & USE_DIR )
  669.     {
  670.         if ( dir == noData )
  671.         {
  672.             if ( (info & CAN_NO_DATA) != CAN_NO_DATA )
  673.             {
  674.                 return err = SCSI_NEED_INFO;
  675.             }
  676.         }
  677.         else if ( (info & CAN_DATA) != CAN_DATA )
  678.         {
  679.             return err = SCSI_NEED_INFO;
  680.         }
  681.     }
  682.     else
  683.         return err = SCSI_NEED_INFO;
  684.         
  685.     if ( dir != noData )
  686.     {
  687.         //
  688.         // SCSIManager seems to update scParam1 on scInc only if the scInc did
  689.         // not fail.  Thus, if we need to know the exact data count, we need
  690.         // to use a loop, doing on scInc for each byte.
  691.         //
  692.         // If the dataLen is not a multiple of 0x200, we assume the user needs
  693.         // to know the exact amount, and so we loop.  If the dataLen is a multiple
  694.         // of 0x200, we assume it is a read or write to a blocked device, and the
  695.         // user wants efficiency more than an exact byte count.
  696.         //
  697.         if ( dataLen & 0x1ff )
  698.         {
  699.             xfer[0].scOpcode = scInc;
  700.             xfer[0].scParam1 = (unsigned long)dataPtr;
  701.             xfer[0].scParam2 = 1;
  702.             xfer[1].scOpcode = scLoop;
  703.             xfer[1].scParam1 = -10;
  704.             xfer[1].scParam2 = dataLen;
  705.             xfer[2].scOpcode = scStop;
  706.         }
  707.         else
  708.         {
  709.             xfer[0].scOpcode = scInc;
  710.             xfer[0].scParam1 = (unsigned long)dataPtr;
  711.             xfer[0].scParam2 = dataLen;
  712.             xfer[1].scOpcode = scStop;
  713.         }
  714.     }
  715.     
  716.     moved = 0;
  717.     
  718.     err = SCSIGet();
  719.     if ( err )
  720.         return err;
  721.         
  722.     err = SCSISelect( targetID );
  723.     if ( err )
  724.         return err;
  725.         
  726.     err = SCSICmd( (Ptr)cdb, cdbLen );
  727.     if ( err )
  728.     {
  729.         SCSIComplete( &status, &message, 60L );
  730.         return err;
  731.     }
  732.     
  733.     if ( dir == dataIn )
  734.         err = SCSIRead( (Ptr)xfer );
  735.     else if ( dir == dataOut )
  736.         err = SCSIWrite( (Ptr)xfer );
  737.         
  738.     moved = xfer[0].scParam1 - (unsigned long)dataPtr;
  739.     
  740.     if ( err && err != scPhaseErr )
  741.     {
  742.         SCSIComplete( &status, &message, 60L );
  743.         return err;
  744.     }
  745.     
  746.     err = SCSIComplete( &status, &message, timeout );
  747.     
  748.     return err;
  749. }
  750.  
  751. short    CSCSIOp::getStatus( void )
  752. {
  753.     return status;
  754. }
  755.  
  756. short    CSCSIOp::getMessage( void )
  757. {
  758.     return message;
  759. }
  760.  
  761. void    CSCSIOp::setTimeout( long newTime )
  762. {
  763.     timeout = newTime;
  764. }
  765.  
  766. OSErr    CSCSIOp::getErr( void )
  767. {
  768.     return err;
  769. }
  770.  
  771. long    CSCSIOp::getMoved( void )
  772. {
  773.     return moved;
  774. }
  775.  
  776. - ----- excerpt from main.cp ------
  777.  
  778. uchar    buf[256];
  779.  
  780. void    main( void )
  781. {
  782.     long    i;
  783.     int        id;
  784.     CSCSIOp    * inq = new CSCSIOp;
  785.     CSCSIOp * cmd = new CSCSIOp;
  786.     CSCSIOp * rew = new CSCSIOp;
  787.     CSCSIOp * load = new CSCSIOp;
  788.     CSCSIOp * sense = new CSCSIOp;
  789.     
  790.     cout << "Tape drive simple test v0.00" << endl;
  791.     
  792.     inq->set6( 18, 0, 0, 0, 255, 0 );
  793.     inq->setBuf( buf );
  794.     inq->setLen( 255 );
  795.     inq->setDir( dataIn );
  796.     
  797.     //
  798.     // Find the tape drive
  799.     //
  800.     for ( id = 0; id < 7; id++ )
  801.     {
  802.         //
  803.         //First, we issue an INQUIRY to see what kind of device it is.
  804.         //
  805.         inq->keep( USE_CDB | USE_DIR | USE_BUF | USE_LEN );
  806.         inq->setID( id );
  807.         inq->execute();
  808.         if ( inq->getErr() )
  809.             continue;
  810.         //
  811.         // Byte 0 of INQUIRY data contains the device type.
  812.         //
  813.         if ( (buf[0] & 0x1f) == 1 )
  814.         {
  815.             //
  816.             // It's a tape drive
  817.             //
  818.  
  819. - ------------
  820.  
  821. See that "== 1" in that last if statement?  That's where it's checking
  822. for a tape drive.  Change that to 5 for CD-ROM.  If you really want
  823. to be complete, here are the possible devices:
  824.  
  825.     0    Direct-access device (disk)
  826.     1    Sequential-access device (tape)
  827.     2    Printer
  828.     3    Processor
  829.     4    Write-once device (some optical disks)
  830.     5    CD-ROM
  831.     6    Scanner
  832.     7    Optical memory (some optical disks)
  833.     8    Medium changer
  834.     9    Communications
  835.     10-11    Graphic Arts Pre-Press devices
  836.  
  837. --Tim Smith
  838.  
  839. ---------------------------
  840.  
  841. >From krame893@cs.uidaho.edu (Brian Kramer)
  842. Subject: Lex and Yacc for Mac Programmers
  843. Date: 28 Apr 1994 16:54:36 GMT
  844. Organization: University of Idaho, Moscow, Idaho
  845.  
  846. As the title implies, I am looking for lex and yacc (or their equivalents)
  847. for using for a Mac-based parser of mine.
  848.  
  849. If anyone can give an ftp address, or least let me know that they exist,
  850. I would be _extremely_ appreciative!
  851.  
  852. Brian
  853.  
  854.  
  855.  
  856. =                            =
  857. Brian Kramer
  858. krame893@cs.uidaho.edu
  859. Laboratory for Applied Logic
  860. University of Idaho
  861. Moscow, ID
  862. =                            =
  863.  
  864. +++++++++++++++++++++++++++
  865.  
  866. >From neeri@iis.ee.ethz.ch (Matthias Neeracher)
  867. Date: 29 Apr 94 18:07:22
  868. Organization: Integrated Systems Laboratory, ETH, Zurich
  869.  
  870. In article <2popoc$3hu@owl.csrv.uidaho.edu>, krame893@cs.uidaho.edu (Brian Kramer) writes:
  871.  
  872. > As the title implies, I am looking for lex and yacc (or their equivalents)
  873. > for using for a Mac-based parser of mine.
  874.  
  875. Try:
  876.  
  877. ftp://ftp.switch.ch/software/mac/src/mpw_c/bison-1.22.sit.bin
  878. ftp://ftp.switch.ch/software/mac/src/think_c/Bison-1.18.cpt.bin
  879.  
  880. ftp://ftp.switch.ch/software/mac/src/mpw_c/MPW_Perl_bYacc_181.sit.bin
  881. ftp://ftp.switch.ch/software/mac/src/think_c/BYacc-1.8.2.cpt
  882.  
  883. ftp://ftp.switch.ch/software/mac/src/mpw_c/flex-2.3.8.sit.bin
  884. ftp://ftp.switch.ch/software/mac/src/think_c/Flex-2.3.7.cpt.bin
  885.  
  886. BYacc and Bison are Yacc equivalents. Bison has more faetures, BYacc generates
  887. code without legal restrictions on it. Flex is a lex equivalent.
  888.  
  889. Matthias
  890.  
  891. - ---
  892. Matthias Neeracher                                   neeri@iis.ethz.ch
  893.    "Have you heard of the new Cambridge compilers ? They distribute
  894.     gear-wear much more evenly"
  895.         -- William Gibson/Bruce Sterling, _The Difference Engine_
  896.  
  897.  
  898. +++++++++++++++++++++++++++
  899.  
  900. >From krame893@cs.uidaho.edu (Brian Kramer)
  901. Date: 29 Apr 1994 21:59:55 GMT
  902. Organization: University of Idaho, Moscow, Idaho
  903.  
  904. I have received responses from several people.  I was able to locate
  905. Bison and Yacc (on sumex, umich, among several other places).  Thank
  906. you to those who helped me out.
  907.  
  908. Brian
  909.  
  910.  
  911. : =                            =
  912. : Brian Kramer
  913. : krame893@cs.uidaho.edu
  914. : Laboratory for Applied Logic
  915. : University of Idaho
  916. : Moscow, ID
  917. : =                            =
  918.  
  919. ---------------------------
  920.  
  921. >From bcorrie@csr.UVic.CA (Brian  Corrie)
  922. Subject: PowerMac FP performance - interesting results????
  923. Date: 26 Apr 94 20:59:59 GMT
  924. Organization: University of Victoria
  925.  
  926. G'day folks,
  927.  
  928. I recently got a new toy, a PowerMac 6100 based on the Motorola/IBM/
  929. Apple PowerPC 601 chip. Of course, I was curious how fast it really
  930. was so I have done a bit of benchmarking on my own to see just what
  931. it can do. Some people may have been following the thread about slow
  932. floating point performance using sin/cos over the last week or so. This
  933. little test is similar to that except that it does not use sin/cos.
  934. Here are the results that I have seen thus far.
  935.  
  936. Timing statistics for a numerically intensive computation: 
  937.  
  938. The code performs typical 3D shading calculations (as would be found in a 3D
  939. renderer such as a ray tracer or scan-line renderer) a whole bunch of times
  940. in a tight loop. Timings were done on a IBM RS6000 (POWERStation 375) a
  941. SPARC 10, a SPARC 2 GX, a PowerMac 7100 (PowerPC @ 66Mhz), a PowerMac 6100 
  942. (PowerPC @ 60Mhz), a Quadra 840 (68040 @ 40MHz), and a NeXTstation
  943. (68040 @ ??Mhz).
  944.  
  945. Optimization codes for CodeWarrior are:
  946.  
  947. Peep == peephole optimization
  948. Glob == global optimization
  949. IS   == instruction shceduling
  950.  
  951. Machine           Time (seconds)    Compiler        Optimization?
  952. =====================================================================
  953. RS6000            4.1        xlC        -O2
  954. RS6000            4.1        xlC        -O
  955. RS6000            4.9        xlC        none
  956. RS6000            5.1        xlC        -g
  957.  
  958. SPARC 10        4.7        acc        -O2 libm.il
  959. SPARC 10        4.9        acc        -O2
  960. SPARC 10        4.9        acc        -O
  961. SPARC 10        5.6        acc        none
  962. SPARC 10        5.7        acc        -g
  963.  
  964. SPARC 2GX        11.6        acc        -O2
  965. SPARC 2GX        13.9        acc        none
  966.  
  967. PowerMac 7100        12        CodeWarrior    some??
  968. PowerMac 6100        16.52        CodeWarrior    Peep
  969. PowerMac 6100        16.56        CodeWarrior    Peep + Glob
  970. PowerMac 6100        16.43        CodeWarrior    Peep + Glob + IS
  971. PowerMac 6100        16.15        CodeWarrior    Peep + Glob + IS
  972.                             No extensions
  973.  
  974. NeXTstation        32.9        gcc        -O2
  975.  
  976. Quadra 840        34        Symantec    All
  977.  
  978.  
  979. So what does this mean??? You got me, but its interesting. A few things
  980. to note with the above numbers. I know a fair bit about how to get as
  981. much floating point grunt out of the SPARC 10 so those numbers might be
  982. a bit lower than they should (especially due to the use of inline functions
  983. for math (libm.il)). The PowerMac numbers I achieved are also worthy of
  984. comment. I don't know much about getting performance out of the Mac. Are
  985. there special libraries to link in that are faster???? Also, the
  986. CodeWarrior compiler I have is a Beta release and Metrowerks (the company
  987. that makes it) states clearly that their optimizations are 
  988. minimal at this time. Thus no matter what optimizations I used, the
  989. time did not change significantly. Also, neither the PM 7100 or the PM 6100
  990. have a Level 2 instruction cache. This is supposed to increase the
  991. performance of the machine quite drastically. Anyone out there at UVic
  992. got a PowerMac 8100 that I can run this test on (the 8100 comes standard
  993. with the Level 2 cache).
  994.  
  995. What else have I noticed? If you can avoid it, DO NOT use sin/cos/tan
  996. on the PowerMacs, their implementation is terribly slow. A similar
  997. test to the one above results in the PowerMac being slower than the
  998. Quadra 840AV. Strange, but true....
  999.  
  1000. Overall, I am a bit disapointed that the performance wasn't a bit closer
  1001. to the SPARC 10 and further from the 68040 based machines. That is what
  1002. I would have expected, but that mat be explainable by the 60Mhz clock
  1003. on my machine and no Level 2 cache.
  1004.  
  1005. Any comments????
  1006.  
  1007.     Brian
  1008.  
  1009.  
  1010.  
  1011. --
  1012.                   Brian Corrie (bcorrie@csr.uvic.ca)
  1013. Under the most rigorously controlled conditions of pressure, temperature,
  1014. volume, humidity and other variables, the organism will do as it damn well
  1015. pleases. Sounds like some of the code I have written......  8-)
  1016.  
  1017. +++++++++++++++++++++++++++
  1018.  
  1019. >From tmcgrath@netcom10.netcom.com (Timothy McGrath)
  1020. Date: Wed, 27 Apr 1994 23:20:27 GMT
  1021. Organization: NETCOM On-line services
  1022.  
  1023. In article <bcorrie.767393999@tara> bcorrie@csr.UVic.CA (Brian  Corrie) writes:
  1024.  
  1025. >Machine           Time (seconds)    Compiler        Optimization?
  1026. >=====================================================================
  1027. >RS6000            4.1        xlC        -O2
  1028. >RS6000            4.1        xlC        -O
  1029. >RS6000            4.9        xlC        none
  1030. >RS6000            5.1        xlC        -g
  1031. >
  1032. >SPARC 10        4.7        acc        -O2 libm.il
  1033. >SPARC 10        4.9        acc        -O2
  1034. >SPARC 10        4.9        acc        -O
  1035. >SPARC 10        5.6        acc        none
  1036. >SPARC 10        5.7        acc        -g
  1037. >
  1038. >SPARC 2GX        11.6        acc        -O2
  1039. >SPARC 2GX        13.9        acc        none
  1040. >
  1041. >PowerMac 7100        12        CodeWarrior    some??
  1042. >PowerMac 6100        16.52        CodeWarrior    Peep
  1043. >PowerMac 6100        16.56        CodeWarrior    Peep + Glob
  1044. >PowerMac 6100        16.43        CodeWarrior    Peep + Glob + IS
  1045. >PowerMac 6100        16.15        CodeWarrior    Peep + Glob + IS
  1046. >                            No extensions
  1047. >
  1048. >NeXTstation        32.9        gcc        -O2
  1049. >
  1050. >Quadra 840        34        Symantec    All
  1051. >
  1052.  
  1053. These very interesting numeric results are showing surprisingly poor PPC
  1054. performance in comparison to Sun and IBM RISC workstations. The results are
  1055. at clear odds with published specmarks from IEEE Spectrum a few months ago.
  1056.  
  1057. >So what does this mean??? You got me, but its interesting. A few things
  1058.  
  1059. This continues a pattern that I've long observed: there seems to be
  1060. something about the Mac that produces poor performance using standard
  1061. compilers (MPW, Symantic, or CW).  For instance, the deleted figures show
  1062. that a 25 MHz 68040 NeXT does the computation faster than the 40Mhz 68040
  1063. in the Quadra 840AV.
  1064.  
  1065. I compiled POV-Ray, a popular freeware raytracer, on a 25Mhz 68040 unix box
  1066. and compared POV-Ray's performance to my own 33Mhz 68040-based Mac
  1067. (with cache; Symantec C 6.0). The results for such a floating-point
  1068. intensive application: the Unix box won by being 30% faster!! (Worse still,
  1069. yer bog $1500 486-66 runs the same app about 50% faster than the Unix box).
  1070.  
  1071. I don't know if the problem is poor compiler optimization, poor runtime
  1072. libraries, poor performance out of system software, or bottlenecks in the Mac
  1073. hardware. I'm about the biggest Mac fan there is, and I'm really unhappy
  1074. that my favorite computer is such a performance dog.
  1075. -- 
  1076. Tim McGrath ----- tmcgrath@netcom.com ----- "Minimalist signaturist"
  1077.  
  1078. +++++++++++++++++++++++++++
  1079.  
  1080. >From greer@utdallas.edu (Dale M. Greer)
  1081. Date: 28 Apr 1994 03:45:38 GMT
  1082. Organization: The University of Texas at Dallas
  1083.  
  1084. Brian  Corrie (bcorrie@csr.UVic.CA) wrote:
  1085. > G'day folks,
  1086.  
  1087. > Timing statistics for a numerically intensive computation: 
  1088.  
  1089. > The code performs typical 3D shading calculations (as would be found in a 3D
  1090. > renderer such as a ray tracer or scan-line renderer) a whole bunch of times
  1091. > in a tight loop. Timings were done on a IBM RS6000 (POWERStation 375) a
  1092. > SPARC 10, a SPARC 2 GX, a PowerMac 7100 (PowerPC @ 66Mhz), a PowerMac 6100 
  1093. > (PowerPC @ 60Mhz), a Quadra 840 (68040 @ 40MHz), and a NeXTstation
  1094. > (68040 @ ??Mhz).
  1095.  
  1096. > Optimization codes for CodeWarrior are:
  1097.  
  1098. > Peep == peephole optimization
  1099. > Glob == global optimization
  1100. > IS   == instruction shceduling
  1101.  
  1102. But are you using SANE on the Mac?
  1103.  
  1104. [...]
  1105. > What else have I noticed? If you can avoid it, DO NOT use sin/cos/tan
  1106. > on the PowerMacs, their implementation is terribly slow. A similar
  1107. > test to the one above results in the PowerMac being slower than the
  1108. > Quadra 840AV. Strange, but true....
  1109.  
  1110. Bummer!  Sounds like SANE.  I once wrote a floating point library for
  1111. the 68K that had a sin/cos/tan about 10 times faster than SANE.  The
  1112. PowerMac doesn't have to be that slow.  Maybe MetroWerks will tap IBM
  1113. for a good algorithm.
  1114.  
  1115. --
  1116.  
  1117. Dale Greer, greer@utdallas.edu
  1118. "They know that it is human nature to take up causes whereby a man may
  1119.  oppress his neighbor, no matter how unjustly. ... Hence they have had
  1120.  no trouble in finding men who would preach the damnability and heresy
  1121.  of the new doctrine from the very pulpit..." - Galileo Galilei, 1615
  1122.  
  1123.  
  1124. +++++++++++++++++++++++++++
  1125.  
  1126. >From sdoran@cis.ksu.edu (Steven D. Marcotte)
  1127. Date: 28 Apr 94 06:29:45 GMT
  1128. Organization: Kansas State University
  1129.  
  1130. tmcgrath@netcom10.netcom.com (Timothy McGrath) writes:
  1131.  
  1132. >In article <bcorrie.767393999@tara> bcorrie@csr.UVic.CA (Brian  Corrie) writes:
  1133.  
  1134. >>Machine           Time (seconds)    Compiler        Optimization?
  1135. >>=====================================================================
  1136. >>RS6000            4.1        xlC        -O2
  1137. >>RS6000            4.1        xlC        -O
  1138. >>RS6000            4.9        xlC        none
  1139. >>RS6000            5.1        xlC        -g
  1140. >>
  1141. >>SPARC 10        4.7        acc        -O2 libm.il
  1142. >>SPARC 10        4.9        acc        -O2
  1143. >>SPARC 10        4.9        acc        -O
  1144. >>SPARC 10        5.6        acc        none
  1145. >>SPARC 10        5.7        acc        -g
  1146. >>
  1147. >>SPARC 2GX        11.6        acc        -O2
  1148. >>SPARC 2GX        13.9        acc        none
  1149. >>
  1150. >>PowerMac 7100        12        CodeWarrior    some??
  1151. >>PowerMac 6100        16.52        CodeWarrior    Peep
  1152. >>PowerMac 6100        16.56        CodeWarrior    Peep + Glob
  1153. >>PowerMac 6100        16.43        CodeWarrior    Peep + Glob + IS
  1154. >>PowerMac 6100        16.15        CodeWarrior    Peep + Glob + IS
  1155. >>                            No extensions
  1156. >>
  1157. >>NeXTstation        32.9        gcc        -O2
  1158. >>
  1159. >>Quadra 840        34        Symantec    All
  1160. >>
  1161.  
  1162. >These very interesting numeric results are showing surprisingly poor PPC
  1163. >performance in comparison to Sun and IBM RISC workstations. The results are
  1164. >at clear odds with published specmarks from IEEE Spectrum a few months ago.
  1165.  
  1166. >>So what does this mean??? You got me, but its interesting. A few things
  1167.  
  1168. >This continues a pattern that I've long observed: there seems to be
  1169. >something about the Mac that produces poor performance using standard
  1170. >compilers (MPW, Symantic, or CW).  For instance, the deleted figures show
  1171. >that a 25 MHz 68040 NeXT does the computation faster than the 40Mhz 68040
  1172. >in the Quadra 840AV.
  1173.  
  1174.     I may be way off here but, with Symantec C++ at least, you can
  1175. compile a straight ANSI C program.  If you do, the compiler will
  1176. generate a window for you to do I/O with, I assume with an appropriate
  1177. event loop.  I would imagine this is where a lot of the slow down is,
  1178. waiting for events.  If you are ambitious, try porting your stuff so
  1179. don't wait for events until all your calculations are done and see how
  1180. that compairs.
  1181.  
  1182. Steven
  1183.  
  1184. -- 
  1185.  
  1186.                                         Steven Marcotte
  1187.                                         sdoran@cis.ksu.edu
  1188.  
  1189. +++++++++++++++++++++++++++
  1190.  
  1191. >From palais@binah.cc.brandeis.edu
  1192. Date: Thu, 28 Apr 1994 13:00:21 GMT
  1193. Organization: Brandeis University
  1194.  
  1195. It seems to be pretty "well-known" that the reason that SANE has
  1196. a reputation for being slow is connected mainly with a few
  1197. transcendental functions which, to get the guaranteed accuracy
  1198. need a lot of computation. Most of the basic routines are in fact
  1199. quite fast. Since for most purposes SANE accuracy is overkill,
  1200. but SANE is still a better way to go than direct FPU calls 
  1201. (for compatibility reasons---particularly with the PowerPC), 
  1202. the obvious approach is to re-write these transcendental functions
  1203. using lower tolerances. I'm sure this is no big deal---one could
  1204. crib the algorithms from Numerical Recipes or IMSL. But just what
  1205. are the offending routines? I assume they are sin and cos, but does
  1206. anyone really know?
  1207.  
  1208. +++++++++++++++++++++++++++
  1209.  
  1210. >From bcorrie@csr.UVic.CA (Brian  Corrie)
  1211. Date: 28 Apr 94 19:05:36 GMT
  1212. Organization: University of Victoria
  1213.  
  1214. tmcgrath@netcom10.netcom.com (Timothy McGrath) writes:
  1215. >In article <bcorrie.767393999@tara> bcorrie@csr.UVic.CA (Brian  Corrie) writes:
  1216.  
  1217. >>Machine           Time (seconds)    Compiler        Optimization?
  1218. >>=====================================================================
  1219. >>RS6000            4.1        xlC        -O2
  1220. >>RS6000            4.1        xlC        -O
  1221. >>RS6000            4.9        xlC        none
  1222. >>RS6000            5.1        xlC        -g
  1223. >>
  1224. >>SPARC 10        4.7        acc        -O2 libm.il
  1225. >>SPARC 10        4.9        acc        -O2
  1226. >>SPARC 10        4.9        acc        -O
  1227. >>SPARC 10        5.6        acc        none
  1228. >>SPARC 10        5.7        acc        -g
  1229. >>
  1230. >>SPARC 2GX        11.6        acc        -O2
  1231. >>SPARC 2GX        13.9        acc        none
  1232. >>
  1233. >>PowerMac 7100        12        CodeWarrior    some??
  1234. >>PowerMac 6100        16.52        CodeWarrior    Peep
  1235. >>PowerMac 6100        16.56        CodeWarrior    Peep + Glob
  1236. >>PowerMac 6100        16.43        CodeWarrior    Peep + Glob + IS
  1237. >>PowerMac 6100        16.15        CodeWarrior    Peep + Glob + IS
  1238. >>                            No extensions
  1239. >>
  1240. >>NeXTstation        32.9        gcc        -O2
  1241. >>
  1242. >>Quadra 840        34        Symantec    All
  1243. >>
  1244.  
  1245. >These very interesting numeric results are showing surprisingly poor PPC
  1246. >performance in comparison to Sun and IBM RISC workstations. The results are
  1247. >at clear odds with published specmarks from IEEE Spectrum a few months ago.
  1248.  
  1249. The processor used in the IEEE article (I assume you are talking about
  1250. "The New Contenders", December 1993) is an 80 MHz 601. I wouldn't be
  1251. surprised if it had a cache as well (not clear to me in the table on
  1252. page 21). Thus this would be a similar setup to that in the 8100. I haven't
  1253. seen a test result from such a machine yet so hopefully it will be better.
  1254. It may turn out that with good optimizations (which CodeWarrior does not do),
  1255. an 80MHz 601, and a level 2 cache, the PowerMac's might come close to
  1256. the SPARC 10 as one would expect/hope. I am not ready to moan about the
  1257. performance just yet....  8-)  I will include the code I used below
  1258. if anyone with an 8100 wants to try it out....
  1259.  
  1260. >>So what does this mean??? You got me, but its interesting. A few things
  1261.  
  1262. >This continues a pattern that I've long observed: there seems to be
  1263. >something about the Mac that produces poor performance using standard
  1264. >compilers (MPW, Symantic, or CW).  For instance, the deleted figures show
  1265. >that a 25 MHz 68040 NeXT does the computation faster than the 40Mhz 68040
  1266. >in the Quadra 840AV.
  1267.  
  1268. Hopefully, the compilers will get better.... the sooner the better.
  1269.  
  1270. >I don't know if the problem is poor compiler optimization, poor runtime
  1271. >libraries, poor performance out of system software, or bottlenecks in the Mac
  1272. >hardware. I'm about the biggest Mac fan there is, and I'm really unhappy
  1273. >that my favorite computer is such a performance dog.
  1274.  
  1275. I would say a bit of each of the above. As time goes by hopefully the
  1276. various groups involved (Apple, Compiler types, etc.) will spend more
  1277. time optimizing for the new machines. Libraries will improve over time.
  1278. Hopefully the compilers will improve very quickly....
  1279.  
  1280.     Brian
  1281.  
  1282. ======================================================================
  1283.  
  1284.  
  1285. /* Note this is the UNIX version of the code. I used TickCount()
  1286.    on the Mac to get my timing results.
  1287.  */
  1288.  
  1289. #include <stdio.h>
  1290. #include <math.h>
  1291.  
  1292. #define SL_VECDOT( A,B )   ((A)[0]*(B)[0]+(A)[1]*(B)[1]+(A)[2]*(B)[2])
  1293. #define SL_VECLEN( A )     (sqrt((A)[0]*(A)[0]+(A)[1]*(A)[1]+(A)[2]*(A)[2]))
  1294. #define SL_VECCROSS( A,B,C ) \
  1295.     {                     \
  1296.          (C)[0] = (A)[1]*(B)[2] - (A)[2]*(B)[1] ; \
  1297.          (C)[1] = (A)[2]*(B)[0] - (A)[0]*(B)[2] ; \
  1298.          (C)[2] = (A)[0]*(B)[1] - (A)[1]*(B)[0] ; \
  1299.     }
  1300. #define SL_VECMULT( a,A,B ) \
  1301.     {                    \
  1302.          (B)[0]=(a)*(A)[0] ; \
  1303.          (B)[1]=(a)*(A)[1] ; \
  1304.          (B)[2]=(a)*(A)[2] ; \
  1305.     }
  1306. #define SL_VECDIV( a,A,B ) \
  1307.     {                    \
  1308.          (B)[0]=(A)[0]/(a) ; \
  1309.          (B)[1]=(A)[1]/(a) ; \
  1310.          (B)[2]=(A)[2]/(a) ; \
  1311.     }
  1312.  
  1313. #define SL_VECADD( A,B,C ) \
  1314.     {                   \
  1315.         (C)[0]=(A)[0]+(B)[0] ; \
  1316.         (C)[1]=(A)[1]+(B)[1] ; \
  1317.         (C)[2]=(A)[2]+(B)[2] ; \
  1318.     }
  1319.  
  1320. #define SL_VECADDS( a,A,B,C ) \
  1321.     {                      \
  1322.          (C)[0] = (a) * (A)[0] + (B)[0] ; \
  1323.          (C)[1] = (a) * (A)[1] + (B)[1] ; \
  1324.          (C)[2] = (a) * (A)[2] + (B)[2] ; \
  1325.     }
  1326.  
  1327.  
  1328. main(argc, argv)
  1329.   int argc;
  1330.   char **argv;
  1331. {
  1332.   register int i;
  1333.   register int MAXI;
  1334.   double N[3], L[3], Cl[3], C[3];
  1335.   double len, dot;
  1336.  
  1337.   N[0] = 1.0;
  1338.   N[1] = 2.0;
  1339.   N[2] = 3.5;
  1340.   L[0] = 1.8;
  1341.   L[1] = 0.2;
  1342.   L[2] = 1.4;
  1343.   Cl[0] = 1.5;
  1344.   Cl[1] = -0.2;
  1345.   Cl[2] = 1.9;
  1346.   C[0] = 0.0;
  1347.   C[1] = 0.0;
  1348.   C[2] = 0.0;
  1349.  
  1350.   if (argc < 2) MAXI = 1000;
  1351.   else MAXI = atoi(argv[1]);
  1352.   printf("Loop count = %d\n", MAXI);
  1353.  
  1354.   for(i=0 ; i<MAXI ; i++)
  1355.   {
  1356.     len = sqrt(SL_VECDOT(N, N));
  1357.     if (len != 0.0) SL_VECDIV(len, N, N);
  1358.  
  1359.     len = sqrt(SL_VECDOT(L, L));
  1360.     if (len != 0.0) SL_VECDIV(len, L, L);
  1361.  
  1362.     dot = SL_VECDOT(N, L);
  1363.     if (dot > 0.0) SL_VECADDS(dot, Cl, C, C);
  1364.  
  1365.   }
  1366.   printf("Color = %g, %g, %g\n", C[0], C[1], C[2]);
  1367. }
  1368.  
  1369.  
  1370. --
  1371.                   Brian Corrie (bcorrie@csr.uvic.ca)
  1372. Under the most rigorously controlled conditions of pressure, temperature,
  1373. volume, humidity and other variables, the organism will do as it damn well
  1374. pleases. Sounds like some of the code I have written......  8-)
  1375.  
  1376. +++++++++++++++++++++++++++
  1377.  
  1378. >From bcorrie@csr.UVic.CA (Brian  Corrie)
  1379. Date: 28 Apr 94 19:20:05 GMT
  1380. Organization: University of Victoria
  1381.  
  1382. greer@utdallas.edu (Dale M. Greer) writes:
  1383.  
  1384. >Brian  Corrie (bcorrie@csr.UVic.CA) wrote:
  1385. >> G'day folks,
  1386.  
  1387. >> Timing statistics for a numerically intensive computation: 
  1388.  
  1389. >> The code performs typical 3D shading calculations (as would be found in a 3D
  1390. >> renderer such as a ray tracer or scan-line renderer) a whole bunch of times
  1391. >> in a tight loop. Timings were done on a IBM RS6000 (POWERStation 375) a
  1392. >> SPARC 10, a SPARC 2 GX, a PowerMac 7100 (PowerPC @ 66Mhz), a PowerMac 6100 
  1393. >> (PowerPC @ 60Mhz), a Quadra 840 (68040 @ 40MHz), and a NeXTstation
  1394. >> (68040 @ ??Mhz).
  1395.  
  1396. >> Optimization codes for CodeWarrior are:
  1397.  
  1398. >> Peep == peephole optimization
  1399. >> Glob == global optimization
  1400. >> IS   == instruction shceduling
  1401.  
  1402. >But are you using SANE on the Mac?
  1403.  
  1404. Not as far as I know. Just doing multiplies, adds, divisions, and one sqrt
  1405. per iteration through the loop. I posted the code in response to another
  1406. article in this thread if anyone is interested.
  1407.  
  1408.     Brian
  1409. --
  1410.                   Brian Corrie (bcorrie@csr.uvic.ca)
  1411. Under the most rigorously controlled conditions of pressure, temperature,
  1412. volume, humidity and other variables, the organism will do as it damn well
  1413. pleases. Sounds like some of the code I have written......  8-)
  1414.  
  1415. +++++++++++++++++++++++++++
  1416.  
  1417. >From nagle@netcom.com (John Nagle)
  1418. Date: Thu, 28 Apr 1994 19:19:56 GMT
  1419. Organization: NETCOM On-line Communication Services (408 241-9760 guest)
  1420.  
  1421. palais@binah.cc.brandeis.edu writes:
  1422. >It seems to be pretty "well-known" that the reason that SANE has
  1423. >a reputation for being slow is connected mainly with a few
  1424. >transcendental functions which, to get the guaranteed accuracy
  1425. >need a lot of computation. Most of the basic routines are in fact
  1426. >quite fast. Since for most purposes SANE accuracy is overkill,
  1427. >but SANE is still a better way to go than direct FPU calls 
  1428. >(for compatibility reasons---particularly with the PowerPC), 
  1429.  
  1430.       Nah.  You're guaranteed that an FPU is present on PPC, so use it.
  1431. Worse, "double" using SANE is 80 bits, and the PPC has only 64-bit
  1432. floating point hardware, which makes 80-bit floating point expensive.
  1433.  
  1434.       SANE is slow because you spend so much time pushing big floating
  1435. point objects on the stack and taking them off the stack.  You lose
  1436. a factor of 10 with SANE on 68K macs equipped with FPUs for multiply.
  1437.  
  1438.                         John Nagle
  1439.  
  1440. +++++++++++++++++++++++++++
  1441.  
  1442. >From bcorrie@csr.UVic.CA (Brian  Corrie)
  1443. Date: 28 Apr 94 23:35:40 GMT
  1444. Organization: University of Victoria
  1445.  
  1446. sdoran@cis.ksu.edu (Steven D. Marcotte) writes:
  1447. >tmcgrath@netcom10.netcom.com (Timothy McGrath) writes:
  1448. >>In article <bcorrie.767393999@tara> bcorrie@csr.UVic.CA (Brian  Corrie) writes:
  1449. [Bunch of stats deleted]
  1450. >>These very interesting numeric results are showing surprisingly poor PPC
  1451. >>performance in comparison to Sun and IBM RISC workstations. The results are
  1452. >>at clear odds with published specmarks from IEEE Spectrum a few months ago.
  1453.  
  1454. >>>So what does this mean??? You got me, but its interesting. A few things
  1455.  
  1456. >>This continues a pattern that I've long observed: there seems to be
  1457. >>something about the Mac that produces poor performance using standard
  1458. >>compilers (MPW, Symantic, or CW).  For instance, the deleted figures show
  1459. >>that a 25 MHz 68040 NeXT does the computation faster than the 40Mhz 68040
  1460. >>in the Quadra 840AV.
  1461.  
  1462. >    I may be way off here but, with Symantec C++ at least, you can
  1463. >compile a straight ANSI C program.  If you do, the compiler will
  1464. >generate a window for you to do I/O with, I assume with an appropriate
  1465. >event loop.  I would imagine this is where a lot of the slow down is,
  1466. >waiting for events.  If you are ambitious, try porting your stuff so
  1467. >don't wait for events until all your calculations are done and see how
  1468. >that compairs.
  1469.  
  1470. With CodeWarrior, you get a IO window, but as far as I know there is 
  1471. no event loop, the benchmark program is in total control of the machine
  1472. (at least it control mine, short of forcing it to quit). I don't
  1473. think that is the source of much of the slow down anyway. Of course
  1474. I am no expert and may be completely out to lunch 8-)
  1475.  
  1476.     Brian
  1477. --
  1478.                   Brian Corrie (bcorrie@csr.uvic.ca)
  1479. Under the most rigorously controlled conditions of pressure, temperature,
  1480. volume, humidity and other variables, the organism will do as it damn well
  1481. pleases. Sounds like some of the code I have written......  8-)
  1482.  
  1483. +++++++++++++++++++++++++++
  1484.  
  1485. >From bcorrie@csr.UVic.CA (Brian  Corrie)
  1486. Date: 28 Apr 94 23:39:19 GMT
  1487. Organization: University of Victoria
  1488.  
  1489. palais@binah.cc.brandeis.edu writes:
  1490. >It seems to be pretty "well-known" that the reason that SANE has
  1491. >a reputation for being slow is connected mainly with a few
  1492. >transcendental functions which, to get the guaranteed accuracy
  1493. >need a lot of computation. Most of the basic routines are in fact
  1494. >quite fast. Since for most purposes SANE accuracy is overkill,
  1495. >but SANE is still a better way to go than direct FPU calls 
  1496. >(for compatibility reasons---particularly with the PowerPC), 
  1497. >the obvious approach is to re-write these transcendental functions
  1498. >using lower tolerances. I'm sure this is no big deal---one could
  1499. >crib the algorithms from Numerical Recipes or IMSL. But just what
  1500. >are the offending routines? I assume they are sin and cos, but does
  1501. >anyone really know?
  1502.  
  1503. So maybe someone can tell me. If I use CodeWarrior, include the ANSI
  1504. library and the MathLibrary, am I using SANE????? I don't think I am,
  1505. but I may be wrong!?!?
  1506.  
  1507. My experiences thus far show that a computation that uses all sin/cos
  1508. calls is HORRIBLY slow on the PowerMacs. Slower even than a Quadra 840.
  1509. And yes, that is native PowerMac code. Obviously the sin/cos implementation
  1510. is faster on the Quadra. Is it a hardware calculation on the Quadra's
  1511. floating point unit, or is it less accurate on the Quadra? You got me,
  1512. but I know its slow on the PowerMac!!
  1513.  
  1514.     Brian
  1515.  
  1516.  
  1517. --
  1518.                   Brian Corrie (bcorrie@csr.uvic.ca)
  1519. Under the most rigorously controlled conditions of pressure, temperature,
  1520. volume, humidity and other variables, the organism will do as it damn well
  1521. pleases. Sounds like some of the code I have written......  8-)
  1522.  
  1523. +++++++++++++++++++++++++++
  1524.  
  1525. >From nagle@netcom.com (John Nagle)
  1526. Date: Fri, 29 Apr 1994 02:09:29 GMT
  1527. Organization: NETCOM On-line Communication Services (408 241-9760 guest)
  1528.  
  1529. bcorrie@csr.UVic.CA (Brian  Corrie) answers the question:
  1530. >>But are you using SANE on the Mac?
  1531.  
  1532. >Not as far as I know. Just doing multiplies, adds, divisions, and one sqrt
  1533. >per iteration through the loop. I posted the code in response to another
  1534. >article in this thread if anyone is interested.
  1535.  
  1536.       Try using 8-byte doubles and see if things improve.  PPC doesn't have
  1537. an 80-bit FPU, so 80-bit performance suffers.  Or try using "float" instead
  1538. of "double", which consistently gets you 32-bit floats on all Apple
  1539. platforms.
  1540.  
  1541.                     John Nagle
  1542.  
  1543. +++++++++++++++++++++++++++
  1544.  
  1545. >From 103t_english@west.cscwc.pima.edu
  1546. Date: 29 Apr 94 03:09:48 MST
  1547. Organization: (none)
  1548.  
  1549. In article <1994Apr28.130021.22832@news.cs.brandeis.edu>, palais@binah.cc.brandeis.edu writes:
  1550. > It seems to be pretty "well-known" that the reason that SANE has
  1551. > a reputation for being slow is connected mainly with a few
  1552. > transcendental functions which, to get the guaranteed accuracy
  1553. > need a lot of computation. Most of the basic routines are in fact
  1554. > quite fast. Since for most purposes SANE accuracy is overkill,
  1555. > but SANE is still a better way to go than direct FPU calls 
  1556. > (for compatibility reasons---particularly with the PowerPC), 
  1557. > the obvious approach is to re-write these transcendental functions
  1558. > using lower tolerances. I'm sure this is no big deal---one could
  1559. > crib the algorithms from Numerical Recipes or IMSL. But just what
  1560. > are the offending routines? I assume they are sin and cos, but does
  1561. > anyone really know?
  1562.  
  1563.  
  1564. IF the FPU is present on a 68K Mac, the SANE calls will use it, but only for
  1565. arithmetic. All other SANE calls are done using Apple's own libraries (using
  1566. the fpu for addition/subtraction/etc).
  1567.  
  1568. The overhead from SANE also comes from the fact that it is called via the Trap
  1569. Dispatcher, instead of directly, and that translations between the SANE format
  1570. and the 68881 format need to be done.
  1571.  
  1572.  
  1573. Lawson
  1574.  
  1575. +++++++++++++++++++++++++++
  1576.  
  1577. >From sparent@mv.us.adobe.com (Sean Parent)
  1578. Date: Sat, 30 Apr 1994 00:02:02 GMT
  1579. Organization: Adobe Systems Incorporated
  1580.  
  1581. This is getting awfully messy. The original discussion was talking about
  1582. native floating point performance. Some how the question of SANE came up.
  1583. Let me list some info:
  1584.  
  1585. % On 68K machines w/o an FPU, SANE is a software floating point package
  1586. implemented using integer arithmetic and provides 80bit "extended" floating
  1587. point support. For most (all) operations, floating point types (whether
  1588. double, single, comp, etc.) promote to 80 bit extendes for maximal
  1589. accuracy. Hence, using 80 bit extendeds tends to be fastest. SANE is
  1590. invoked via an A-Trap but in recent systems SANE back pages the calling
  1591. code so the A-Trap overhead is only paid on the first invocation.
  1592.  
  1593. % On 68K machines w/ an FPU, SANE is still available and is implement using
  1594. the FPU for those operations that it can and maintain accuracy. The FPU
  1595. (68881/2 or 040) uses 96bit format but 16 bits are unused so converting
  1596. from 80bit to 96 bit format only requires a shift. Applications can be
  1597. compiled to call the FPU directly and they can check for it via a call to
  1598. Gestalt. On the 040, the transcendental functions are not in the FPU so
  1599. those instructions are handled in software as exceptions.
  1600.  
  1601. % On a Power Mac, running emulated code, there is no emulated FPU so it is
  1602. similar to the first case above except SANE is build into the emulator so
  1603. it is running "native" (though it still only uses integer math to do the fp
  1604. calculations). There is no "Mixed Mode" overhead or A-Trap dispatch
  1605. overhead because SANE is handled as any other instructions (there really
  1606. isn't any "A-Trap" overhead at all on the Power Mac because the A-Trap
  1607. dispatching is handled by the emulator).
  1608.  
  1609. % On a Power Mac, running a "native" application SANE is not available. You
  1610. can't do native 80 or 96bit arithmetic (unless you wan't to implement it
  1611. yourself or call some 68K code to do it). Instead, there is a new numerics
  1612. package based on the NCEG spec. It support most all of what SANE did
  1613. (though a couple of types are missing, like comp) and a bit more. The
  1614. supported types are: float (IEEE single), double (IEEE double), and long
  1615. double (IBM's "double double" which is 128bits and is IEEE extended
  1616. complient).
  1617.  
  1618. A portable application should use floats or doubles for persistent data
  1619. storage (files), float_t or double_t for fast calculations with precision
  1620. and least that of float and double respectively, and long double for
  1621. intermediate results that require extra precision. On the various machines,
  1622. these types are:
  1623.  
  1624.                 68K SANE     68K FPU      PowerPC
  1625. float           32bit        32bit        32bit
  1626. double          64bit        64bit        64bit
  1627. float_t         80bit        96bit        32bit
  1628. double_t        80bit        96bit        64bit
  1629. long double     80bit        96bit       128bit
  1630.  
  1631. Now, I haven't looked at this bench mark that is floating around that shows
  1632. native PPC applications in such bad light but what could attribute to it is
  1633. the compiler (I don't know of a PPC compiler other than xlc that does
  1634. really good FP optimizations), and the floating point library. Last I
  1635. checked Apple's library was a bit slower than IBM's though it was
  1636. considerably more accurate. Someone with some time should compiler the
  1637. "bench mark" with xlc and run it on a PowerMac and time the library
  1638. routines. I know of no reason why there would be any significant difference
  1639. in time between a 66MHz PowerMac and a 66MHz 250 given the same compiler
  1640. and the same libraries.
  1641.  
  1642. -- 
  1643. Sean Parent
  1644.  
  1645. +++++++++++++++++++++++++++
  1646.  
  1647. >From rang@winternet.mpls.mn.us (Anton Rang)
  1648. Date: 29 Apr 1994 23:08:18 GMT
  1649. Organization: Minnesota Angsters
  1650.  
  1651. In article <bcorrie.767576359@tara> bcorrie@csr.UVic.CA (Brian  Corrie) writes:
  1652. >So maybe someone can tell me. If I use CodeWarrior, include the ANSI
  1653. >library and the MathLibrary, am I using SANE????? I don't think I am,
  1654. >but I may be wrong!?!?
  1655.  
  1656.   No, you're not using SANE, unless you're compiling for the 68000.
  1657. SANE is only used on the 68000 series.  It's not available on the
  1658. Power Macintoshes except in emulation mode.
  1659.  
  1660. >My experiences thus far show that a computation that uses all sin/cos
  1661. >calls is HORRIBLY slow on the PowerMacs. Slower even than a Quadra 840.
  1662.  
  1663.   Right.  The transcendental functions are sloooooow.  I don't know
  1664. how much of this is related to supporting the NCEG exception model,
  1665. but I suspect an awful lot of is.  (Alternatively, it could be that
  1666. range reduction is implemented poorly?)
  1667.  
  1668.   After all, to a first approximation, computing a sin requires:
  1669.  
  1670.     (i) Range-reduce to (say) 0 to pi/2.
  1671.         This may require a division (slow) if you're out of the range
  1672.         -pi to +pi, but shouldn't be *that* incredibly slow.
  1673.  
  1674.     (ii) Compute a Taylor series (or a more quickly converging one).
  1675.          I'm not sure how many terms would be required, not being up
  1676.          on state-of-the-art numerical algorithms, but probably not
  1677.          more than 5 or so for single precision, perhaps 8-10 for
  1678.          double precision.  These should be multiply-add, relatively
  1679.          fast.
  1680.  
  1681.     (iii) Do a little cleanup depending on the original sign etc.
  1682.  
  1683. >Is it a hardware calculation on the Quadra's
  1684. >floating point unit, or is it less accurate on the Quadra?
  1685.  
  1686.   Neither, as far as I know (not sure about accuracy).  The 68040
  1687. doesn't have built-in transcendental functions; they're implemented in
  1688. software.  Heck, I've been tempted to disassemble the 68040 FPSP, grab
  1689. the appropriate constants, port it to PPC assembly and time the
  1690. result.  It would be *bound* to be faster than the current one.
  1691.  
  1692.   SOMEONE out there must know the story about why MathLib runs so
  1693. slowly.  Is it the exception handling?  There are a bunch of procedure
  1694. calls in it related to that, and handling all of the boundaries right
  1695. undoubtedly requires a lot of work...sigh.  Wish I knew for sure.
  1696. --
  1697. Anton Rang (rang@winternet.mpls.mn.us)
  1698.  
  1699. +++++++++++++++++++++++++++
  1700.  
  1701. >From jwbaxter@olympus.net (John W. Baxter)
  1702. Date: Sun, 01 May 1994 10:32:08 -0700
  1703. Organization: Internet for the Olympic Peninsula
  1704.  
  1705. In article <TMCGRATH.94Apr27162028@netcom10.netcom.com>,
  1706. tmcgrath@netcom10.netcom.com (Timothy McGrath) wrote:
  1707.  
  1708. [Table of results omitted...it's been quoted many times already.]
  1709. > These very interesting numeric results are showing surprisingly poor PPC
  1710. > performance in comparison to Sun and IBM RISC workstations. The results are
  1711. > at clear odds with published specmarks from IEEE Spectrum a few months ago.
  1712. No...take a look at the improvements for the 6100 as additional
  1713. optimizations are added.  Notice that essentially there aren't any
  1714. improvements.
  1715.  
  1716. What is being compared is optimized code (I suspect, but don't have access
  1717. to the compilers on the other systems compared) versus essentially
  1718. unoptimized code.  With the added complication that different hardware is
  1719. running the optimized code.
  1720.  
  1721.  
  1722. > >So what does this mean???
  1723.  
  1724. It means that CodeWarrior isn't finished.  There are easier ways to learn
  1725. this astounding fact, such as by looking at the version number.
  1726.  
  1727. ****Someone who has the means:
  1728.     Could we run the code in question through the xlc compiler, move it to
  1729. the Mac, and time it?
  1730.  
  1731.     [Given the code, I could now do that for the MPW compiler, which is
  1732. said to lie between xlc and CodeWarrior in current quality...closer to the
  1733. former.]
  1734. -- 
  1735. John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
  1736.    jwbaxter@pt.olympus.net
  1737.  
  1738. +++++++++++++++++++++++++++
  1739.  
  1740. >From John Brewer <jbrewer@wri.com>
  1741. Date: Tue, 3 May 1994 03:11:15 GMT
  1742. Organization: Wolfram Research, Inc.
  1743.  
  1744. In article <bcorrie.767393999@tara> Brian  Corrie, bcorrie@csr.UVic.CA writes:
  1745. >The code performs typical 3D shading calculations (as would be found in a 3D
  1746. >renderer such as a ray tracer or scan-line renderer) a whole bunch of times
  1747. >in a tight loop. Timings were done on a IBM RS6000 (POWERStation 375) a
  1748. >SPARC 10, a SPARC 2 GX, a PowerMac 7100 (PowerPC @ 66Mhz), a PowerMac 6100 
  1749. >(PowerPC @ 60Mhz), a Quadra 840 (68040 @ 40MHz), and a NeXTstation
  1750. >(68040 @ ??Mhz).
  1751.  
  1752. It'd be interresting to try using xlc to generate the PowerMac code.
  1753. It seems to be the best at optimization, although it can easily take up to
  1754. 100 Mb of swap space to compile a large program.
  1755.  
  1756. John Brewer
  1757. Wolfram Research, Inc.
  1758. (but speaking for myself)
  1759.  
  1760. +++++++++++++++++++++++++++
  1761.  
  1762. >From uzun@crash.cts.com (Roger Uzun)
  1763. Date: Tue, 3 May 1994 17:03:00 GMT
  1764. Organization: CTS Network Services (CTSNET/crash), San Diego, CA
  1765.  
  1766. I have this 3D shading code, the tight loop benchmark that
  1767. was circulating around here, but I do not know how
  1768. many loops were performed to get the results that
  1769. were posted was it 1,000,000?
  1770. The default is 1000 and this executes in less than a second
  1771. on all machines around here (040, pentiums, no macs).
  1772. How many iterations were used in the running of this benchmark?
  1773. Also could someone repost any results people came up with.
  1774.  
  1775. -Roger
  1776. - ------------------------------------------------------------
  1777. bix: ruzun
  1778. NET: uzun@crash.cts.com
  1779.  
  1780. +++++++++++++++++++++++++++
  1781.  
  1782. >From bcorrie@csr.UVic.CA (Brian  Corrie)
  1783. Date: 3 May 94 23:47:51 GMT
  1784. Organization: University of Victoria
  1785.  
  1786. uzun@crash.cts.com (Roger Uzun) writes:
  1787. >I have this 3D shading code, the tight loop benchmark that
  1788. >was circulating around here, but I do not know how
  1789. >many loops were performed to get the results that
  1790. >were posted was it 1,000,000?
  1791. >The default is 1000 and this executes in less than a second
  1792. >on all machines around here (040, pentiums, no macs).
  1793. >How many iterations were used in the running of this benchmark?
  1794. >Also could someone repost any results people came up with.
  1795.  
  1796. Oppps, Sorry about that. Yes, 1,000,000 is the correct magic
  1797. number to produce the same results that I got. Please post any
  1798. results that you get....
  1799.  
  1800. Cheers,
  1801.  
  1802.     Brian
  1803.  
  1804. --
  1805.                   Brian Corrie (bcorrie@csr.uvic.ca)
  1806. Under the most rigorously controlled conditions of pressure, temperature,
  1807. volume, humidity and other variables, the organism will do as it damn well
  1808. pleases. Sounds like some of the code I have written......  8-)
  1809.  
  1810. +++++++++++++++++++++++++++
  1811.  
  1812. >From oliver@psy.fsu.edu (Bill Oliver)
  1813. Date: 4 May 1994 14:14:33 GMT
  1814. Organization: FSU Psych Dept
  1815.  
  1816. In article <bcorrie.768008871@tara>
  1817. bcorrie@csr.UVic.CA (Brian  Corrie) writes:
  1818.  
  1819. > uzun@crash.cts.com (Roger Uzun) writes:
  1820. > >I have this 3D shading code, the tight loop benchmark that
  1821. > >was circulating around here, but I do not know how
  1822. > >many loops were performed to get the results that
  1823. > >were posted was it 1,000,000?
  1824. > >The default is 1000 and this executes in less than a second
  1825. > >on all machines around here (040, pentiums, no macs).
  1826. > >How many iterations were used in the running of this benchmark?
  1827. > >Also could someone repost any results people came up with.
  1828. > Oppps, Sorry about that. Yes, 1,000,000 is the correct magic
  1829. > number to produce the same results that I got. Please post any
  1830. > results that you get....
  1831. > Cheers,
  1832. >         Brian
  1833.  
  1834.  
  1835.  
  1836. Your code is taking approximately 35 seconds to run on my Centris
  1837. 660AV. The compiler I'm using is Metrowerks CW C (68020&6881 Codegen, 4
  1838. Byte Ints, Peephole & CSE optimizers). I'm quite happy with this result
  1839. given the other times that were posted (I'm reposting those below). I
  1840. think I'll wait on the PowerMac :-)
  1841.  
  1842. -Bill-
  1843.  
  1844. >>Machine                 Time (seconds)    Compiler       Optimization?
  1845. >>=====================================================================
  1846. >>RS6000                4.1             xlC             -O2
  1847. >>RS6000                4.1             xlC             -O
  1848. >>RS6000                4.9             xlC             none
  1849. >>RS6000                5.1             xlC             -g
  1850. >>
  1851. >>SPARC 10             4.7             acc             -O2 libm.il
  1852. >>SPARC 10             4.9             acc             -O2
  1853. >>SPARC 10             4.9             acc             -O
  1854. >>SPARC 10             5.6             acc             none
  1855. >>SPARC 10             5.7             acc             -g
  1856. >>
  1857. >>SPARC 2GX            11.6            acc             -O2
  1858. >>SPARC 2GX            13.9            acc             none
  1859. >>
  1860. >>PowerMac 7100                12              CodeWarrior     some??
  1861. >>PowerMac 6100                16.52           CodeWarrior     Peep
  1862. >>PowerMac 6100                16.56           CodeWarrior     Peep + Glob
  1863. >>PowerMac 6100                16.43           CodeWarrior     Peep + Glob 
  1864. + IS
  1865. >>PowerMac 6100                16.15           CodeWarrior     Peep + Glob 
  1866. + IS
  1867. >>                                                      No extensions
  1868. >>
  1869. >>NeXTstation          32.9            gcc             -O2
  1870. >>
  1871. >>Quadra 840           34              SymantecAll
  1872.  
  1873. +++++++++++++++++++++++++++
  1874.  
  1875. >From Dave Falkenburg <falken@apple.com>
  1876. Date: Fri, 29 Apr 1994 08:00:16 GMT
  1877. Organization: Apple Computer, Inc.
  1878.  
  1879. In article <TMCGRATH.94Apr27162028@netcom10.netcom.com> Timothy McGrath,
  1880. tmcgrath@netcom10.netcom.com writes:
  1881. >I compiled POV-Ray, a popular freeware raytracer, on a 25Mhz 68040 unix
  1882. box
  1883. >and compared POV-Ray's performance to my own 33Mhz 68040-based Mac
  1884. >(with cache; Symantec C 6.0). The results for such a floating-point
  1885. >intensive application: the Unix box won by being 30% faster!! (Worse
  1886. still,
  1887. >yer bog $1500 486-66 runs the same app about 50% faster than the Unix
  1888. box).
  1889.  
  1890. Are you running the version that calls SetCPixel for every pixel to be
  1891. rendered?
  1892. My brother recompiled POV a couple of months ago and got barn-burning
  1893. performance out of it.
  1894.  
  1895. The Mac-specific stuff in the version you have might be a complete dog.
  1896.  
  1897. >I don't know if the problem is poor compiler optimization, poor runtime
  1898. >libraries, poor performance out of system software, or bottlenecks in
  1899. the Mac
  1900. >hardware. I'm about the biggest Mac fan there is, and I'm really unhappy
  1901. >that my favorite computer is such a performance dog.
  1902.  
  1903. Remember that CW isn't final yet AND this version will not be as good as
  1904. xlc on AIX, or PPCC in the PowerMac SDK.
  1905.  
  1906. One big hog is mathlib--> the AIX libm.a is MUCH faster than one in ROM
  1907. Apple is shipping today-- it's hand tuned code for calculating sin, cos,
  1908. etc.
  1909.  
  1910.  
  1911. If I were a developer, I'd scream at the top of my lungs at the WWDC
  1912. about this...
  1913.  
  1914.  
  1915. -Dave Falkenburg
  1916. -Not speaking for "Apple Computer, Inc." in this posting
  1917.  
  1918. ---------------------------
  1919.  
  1920. >From rcohen@ssl.umd.edu (Rob Cohen)
  1921. Subject: Saving the floating Point Registers
  1922. Date: 26 Apr 1994 20:43:17 GMT
  1923. Organization: Space Systems Laboratory, University of Maryland
  1924.  
  1925. I've written an interrupt service routine that when called does some
  1926. floating point math.  There is also a lot of floating point math that
  1927. goes on in the rest of the code.  Unfortunately, my code crashes when
  1928. I'm running the ISR in places that do math.  I think the problem is
  1929. that I'm not preserving the values in the floating point registers.  I
  1930. think I want to push them on the stack when I enter the ISR, do what I
  1931. have to do and then pop them off.  My question then becomes how do you
  1932. do this.  I know the locations of the floating point register,
  1933. FP0...FP7, but what does the assembler look like to do this.
  1934.  
  1935. Thanks
  1936.  
  1937. - -----------------------------------------------------------------
  1938. Rob Cohen              rcohen@ssl.umd.edu
  1939.  
  1940. The views expressed here are my own Blah, blah, blah, blah (The
  1941. standard disclaimer)
  1942.  
  1943. +++++++++++++++++++++++++++
  1944.  
  1945. >From Ron_Hunsinger@bmug.org (Ron Hunsinger)
  1946. Date: Sun,  1 May 94 23:38:47 PST
  1947. Organization: Berkeley Macintosh Users Group
  1948.  
  1949. rcohen@ssl.umd.edu (Rob Cohen) writes:
  1950.  
  1951. >I've written an interrupt service routine that when called does some
  1952. >floating point math.  There is also a lot of floating point math that
  1953. >goes on in the rest of the code.  Unfortunately, my code crashes when
  1954. >I'm running the ISR in places that do math.  I think the problem is
  1955. >that I'm not preserving the values in the floating point registers.  I
  1956. >think I want to push them on the stack when I enter the ISR, do what I
  1957. >have to do and then pop them off.  My question then becomes how do you
  1958. >do this.  I know the locations of the floating point register,
  1959. >FP0...FP7, but what does the assembler look like to do this.
  1960.  
  1961. It's not just the registers that have to be saved.  You have to save
  1962. the state of the FPU also, since you could have interrupted it in the
  1963. middle of an operation.  In general, you have to:
  1964.  
  1965.     FSAVE    <ea>                   ; save the non-visible state
  1966.     FMOVEM.L FPCR/FPSR/FPIAR, <ea>  ; save the control registers
  1967.     FMOVEM.X FP0-FP7, <ea>          ; save the data registers
  1968.  
  1969.     ; establish the environment you want to run in
  1970.     ;          (rounding rules, traps, etc) because the task you
  1971.     ;          interrupted may have changed them.  A quick way to
  1972.     ;          reset the fpu is to do an FRESTORE from a longword
  1973.     ;          containing $00000000, but this clears ALL the registers
  1974.     ;          so you can't have skimped on any of the above register-
  1975.     ;          saving.
  1976.  
  1977.     ; do your work
  1978.  
  1979.     FMOVEM.X <ea>, FP0-FP7          ; restore the data registers
  1980.     FMOVEM.L <ea>, FPCR/FPSR/FPIAR  ; restore the control registers
  1981.     FRESTORE <ea>                   ; restore the non-visible state
  1982.  
  1983. All of this saving and restoring is not guaranteed to be cheap, which 
  1984. is why it wasn't done automatically for you.
  1985.  
  1986. -Ron Hunsinger
  1987.  
  1988. ---------------------------
  1989.  
  1990. >From Daniel Jibouleau <jiboule@hermes.ulaval.ca>
  1991. Subject: The NewWindow case
  1992. Date: Thu, 28 Apr 1994 23:19:08 GMT
  1993. Organization: Universit Laval
  1994.  
  1995. For a long time now, i am still asking myself whether it is better to
  1996. call NewWindow (or GetNewWindow) with a storage or to let it allocate
  1997. it's storage itself.  Note that both ways may be correct.  Consider the
  1998. following example:
  1999.  
  2000. NewWindow with a storage:
  2001.  
  2002. {
  2003.     WindowPtr theWindow;
  2004.     WindowRecord windStorage;
  2005.     
  2006.     /* Use a pointer to our storage to store the window associated
  2007. information.  It will be stored on the stack, thus reducing heap
  2008. fragmentation. */
  2009.     theWindow = GetNewWindow (&windStorage, fooWindID, (WindowPtr) -1L);
  2010. }
  2011.  
  2012. NewWindow without storage:
  2013.  
  2014. {
  2015.     WindowPtr theWindow;
  2016.     
  2017.     /* Let the Window Manager allocate the storage for the window itself.
  2018.  It will be placed on the heap, thus increasing chances of heap
  2019. fragmentation.  The Window Manager may be doing this in a better way,
  2020. tough. */
  2021.     theWindow = GetNewWindow (nil, fooWindID, (WindowPtr) -1L);
  2022. }
  2023.  
  2024.  
  2025. Daniel Jibouleau
  2026. jiboule@hermes.ulaval.ca
  2027.  
  2028. +++++++++++++++++++++++++++
  2029.  
  2030. >From rmah@panix.com (Robert S. Mah)
  2031. Date: Fri, 29 Apr 1994 10:16:54 -0500
  2032. Organization: One Step Beyond
  2033.  
  2034. Daniel Jibouleau <jiboule@hermes.ulaval.ca> wrote:
  2035.  
  2036. > For a long time now, i am still asking myself whether it is better to
  2037. > call NewWindow (or GetNewWindow) with a storage or to let it allocate
  2038. > it's storage itself.  Note that both ways may be correct.  Consider the
  2039. > following example:
  2040. > NewWindow with a storage:
  2041. > {
  2042. >     WindowPtr theWindow;
  2043. >     WindowRecord windStorage;
  2044. >     
  2045. >     /* Use a pointer to our storage to store the window associated
  2046. > information.  It will be stored on the stack, thus reducing heap
  2047. > fragmentation. */
  2048. >     theWindow = GetNewWindow (&windStorage, fooWindID, (WindowPtr) -1L);
  2049. > }
  2050. > NewWindow without storage:
  2051. > {
  2052. >     WindowPtr theWindow;
  2053. >     
  2054. >     /* Let the Window Manager allocate the storage for the window itself.
  2055. >  It will be placed on the heap, thus increasing chances of heap
  2056. > fragmentation.  The Window Manager may be doing this in a better way,
  2057. > tough. */
  2058. >     theWindow = GetNewWindow (nil, fooWindID, (WindowPtr) -1L);
  2059. > }
  2060.  
  2061. The first example is very, very dangerous.  Since the storage is a local
  2062. variable, and allocated on the stack, it goes away after the function
  2063. is exited.  This is fine if that function is main(), but not the other
  2064. way around.  Better to use a global (or static) if you care about heap
  2065. fragging.
  2066.  
  2067. My rule of thumb is to use static/global (stack based) allocation for
  2068. window storage only if the app only uses a small, fairly constant set 
  2069. of windows.  For apps with user-created documents, static allocation
  2070. is not such a good thing because it would limit the # of docs the user
  2071. could open.
  2072.  
  2073. Cheers,
  2074. Rob
  2075. ___________________________________________________________________________
  2076. Robert S. Mah  -=-  One Step Beyond  -=-  212-947-6507  -=-  rmah@panix.com
  2077.  
  2078. +++++++++++++++++++++++++++
  2079.  
  2080. >From dean@genmagic.com (Dean Yu)
  2081. Date: 29 Apr 1994 17:57:56 GMT
  2082. Organization: General Magic, Inc.
  2083.  
  2084. In article <Cozsrx.6Kp@athena.ulaval.ca>, Daniel Jibouleau
  2085. <jiboule@hermes.ulaval.ca> wrote:
  2086. > For a long time now, i am still asking myself whether it is better to
  2087. > call NewWindow (or GetNewWindow) with a storage or to let it allocate
  2088. > it's storage itself.  Note that both ways may be correct.  Consider the
  2089. > following example:
  2090.  
  2091.   Although allocating the storage space for the window record yourself
  2092. might help your memory management now, it might be a hindrance in the
  2093. future. If Apple ever goes to a protected memory model, it would almost
  2094. definitely be better if the toolbox would be able to allocate its data
  2095. structures in another address space and pass you a reference to that data
  2096. structure. If everyone specified nil as the wStorage parameter now, it
  2097. would be much much simpler for a future Window Manager to change while
  2098. still maintaining API compatibility. But because storage can be allocated
  2099. by the application, it makes moving forward while still maintaining
  2100. compatibility much more difficult.
  2101.   I've gone on tirades about this topic before; it was something I really
  2102. wanted to do at Apple, but never had the time for. :/
  2103.  
  2104. -- Dean Yu
  2105.    Negative Ethnic Role Model
  2106.    General Magic, Inc.
  2107.  
  2108. ---------------------------
  2109.  
  2110. >From ereidell@media.mit.edu (Evan A. Reidell)
  2111. Subject: Truetype font format specification: No longer available from Apple ?!
  2112. Date: Mon, 25 Apr 1994 19:57:29 GMT
  2113. Organization: MIT Media Laboratory
  2114.  
  2115. I have been having a hell of a time trying to find 
  2116. the Apple TrueType font format specification.
  2117.  
  2118. Luckily, this is _theoretically_ available
  2119. as "Apple Finished Goods" product number:
  2120. M0825 LL/A ``TrueType font format specification''
  2121.  
  2122. Unluckily, no one at ALL seems to know anything about it.
  2123.  
  2124. I've been bounced around between Catalog Sales, Apple Authorized Dealers,
  2125. AP.D.A, Apple Customer Assistance, and Apple R&D groups so many times
  2126. that I'm beginning to wonder if the TrueType font format even exists.
  2127.  
  2128. Is it worth the grief??  Or is Adobe PostScript the way to go,
  2129. no matter how Apple and Microsoft would like to play their games?
  2130.  
  2131. Can anyone out there help me get my hands on this "document" ?
  2132.  
  2133. -- evan reidell
  2134.  
  2135. +++++++++++++++++++++++++++
  2136.  
  2137. >From s66039@cc.ntnu.edu.tw (Riboflavin)
  2138. Date: Tue, 26 Apr 1994 09:54:40 GMT
  2139. Organization: NTNU, Taiwan, R.O.C.
  2140.  
  2141. Evan A. Reidell (ereidell@media.mit.edu) wrote:
  2142. : I have been having a hell of a time trying to find 
  2143. : the Apple TrueType font format specification.
  2144. : Unluckily, no one at ALL seems to know anything about it.
  2145. : I've been bounced around between Catalog Sales, Apple Authorized Dealers,
  2146. : AP.D.A, Apple Customer Assistance, and Apple R&D groups so many times
  2147. : that I'm beginning to wonder if the TrueType font format even exists.
  2148. : Is it worth the grief??  Or is Adobe PostScript the way to go,
  2149. : no matter how Apple and Microsoft would like to play their games?
  2150.  
  2151. I don't know, I had an heck of a time getting a particular document from
  2152. Adobe a while back, but they finally came through. As for the TrueType spec.,
  2153. forget Apple. Instead, ftp to ftp.microsoft.com and look for it - it's there!
  2154. Only catch is it comes either as a Windows help file, or as a PC Word 2.0 
  2155. file, the latter of which you should be able to load into your Mac version
  2156. of Word.
  2157.  
  2158. -Steven Fox-
  2159.  
  2160.  
  2161. +++++++++++++++++++++++++++
  2162.  
  2163. >From tkr@puffball.demon.co.uk (Tim Rylance)
  2164. Date: Tue, 26 Apr 1994 11:45:10 +0000
  2165. Organization: Tim Rylance, Bath, UK
  2166.  
  2167. s66039@cc.ntnu.edu.tw (Riboflavin) writes:
  2168.  
  2169. >I don't know, I had an heck of a time getting a particular document from
  2170. >Adobe a while back, but they finally came through. As for the TrueType spec.,
  2171. >forget Apple. Instead, ftp to ftp.microsoft.com and look for it - it's there!
  2172. >Only catch is it comes either as a Windows help file, or as a PC Word 2.0 
  2173. >file, the latter of which you should be able to load into your Mac version
  2174. >of Word.
  2175.  
  2176. There's a Postscript version at
  2177.  
  2178.   ftp.icce.rug.nl:pub/erikjan/truetype/ttspec/*.ps
  2179.  
  2180. --
  2181. Tim Rylance <tkr@puffball.demon.co.uk>
  2182.  
  2183. +++++++++++++++++++++++++++
  2184.  
  2185. >From vens007@telecom.ptt.nl (Erik-Jan Vens,HD,)
  2186. Date: 26 Apr 1994 11:53:04 +0200
  2187. Organization: PTT Telecom B.V. The Netherlands
  2188.  
  2189. dixit ereidell@media.mit.edu (Evan A. Reidell) in <1994Apr25.195729.2855@news.media.mit.edu>:
  2190. >I have been having a hell of a time trying to find 
  2191. >the Apple TrueType font format specification.
  2192. >
  2193. >Luckily, this is _theoretically_ available
  2194. >as "Apple Finished Goods" product number:
  2195. >M0825 LL/A ``TrueType font format specification''
  2196.  
  2197. Supposedly the TrueType format should be the same for DOS and Apple.
  2198. Maybe you should try ftp.icce.rug.nl in pub/erikjan/truetype/ttspec. I
  2199. have converted the MS version to Postscript.
  2200.  
  2201. EJee
  2202.  
  2203. -- 
  2204. - -----------------------------------------------------------------------------
  2205. Erik-Jan Vens             | Telephone: +31 50 855994
  2206. PTT Telecom BV            | Telefax  : +31 50 855777
  2207. I&AT                | E-mail   : vens007@telecom.ptt.nl
  2208. P.O. Box 188            | DISCLAIMER: This statement is not an official
  2209. NL-9700 AD Groningen        | statement from, nor does it represent an
  2210. The Netherlands            | official position of, PTT Telecom B.V.
  2211. - -----------------------------------------------------------------------------
  2212.  
  2213. +++++++++++++++++++++++++++
  2214.  
  2215. >From pan@vaxc.cc.monash.edu.au (Pan Thongvilu)
  2216. Date: 27 Apr 1994 02:34:50 GMT
  2217. Organization: Monash University
  2218.  
  2219. In article <1994Apr26.095440.19400@cc.ntnu.edu.tw>, s66039@cc.ntnu.edu.tw (Riboflavin) writes:
  2220. |> Evan A. Reidell (ereidell@media.mit.edu) wrote:
  2221. |> : I have been having a hell of a time trying to find 
  2222. |> : the Apple TrueType font format specification.
  2223. |> : Unluckily, no one at ALL seems to know anything about it.
  2224. |> : I've been bounced around between Catalog Sales, Apple Authorized Dealers,
  2225. |> : AP.D.A, Apple Customer Assistance, and Apple R&D groups so many times
  2226. |> : that I'm beginning to wonder if the TrueType font format even exists.
  2227. |> : Is it worth the grief??  Or is Adobe PostScript the way to go,
  2228. |> : no matter how Apple and Microsoft would like to play their games?
  2229. |> 
  2230. |> I don't know, I had an heck of a time getting a particular document from
  2231. |> Adobe a while back, but they finally came through. As for the TrueType spec.,
  2232. |> forget Apple. Instead, ftp to ftp.microsoft.com and look for it - it's there!
  2233. |> Only catch is it comes either as a Windows help file, or as a PC Word 2.0 
  2234. |> file, the latter of which you should be able to load into your Mac version
  2235. |> of Word.
  2236. |> 
  2237. |> -Steven Fox-
  2238. |> 
  2239.     Hi,
  2240.  
  2241.     I went to ftp.microsoft.com a couple of times. I looked and looked
  2242.     but could not find it. 
  2243.  
  2244.     Can someone tell us where to find it on the tree and what it is 
  2245.     called so I can do an 'archie -c' on it.
  2246.  
  2247.     Thanks,
  2248.     Pan.
  2249.  
  2250. +++++++++++++++++++++++++++
  2251.  
  2252. >From dmunsil@netcom.com (Don Munsil)
  2253. Date: Wed, 27 Apr 1994 16:48:08 GMT
  2254. Organization: The Munsil/Stone Organization
  2255.  
  2256. Pan Thongvilu (pan@vaxc.cc.monash.edu.au) wrote:
  2257. : In article <1994Apr26.095440.19400@cc.ntnu.edu.tw>, s66039@cc.ntnu.edu.tw (Riboflavin) writes:
  2258. : |> Evan A. Reidell (ereidell@media.mit.edu) wrote:
  2259. : |> : I have been having a hell of a time trying to find 
  2260. : |> : the Apple TrueType font format specification.
  2261.  
  2262. :     I went to ftp.microsoft.com a couple of times. I looked and looked
  2263. :     but could not find it. 
  2264.  
  2265. It's in about the most un-intuitive place imaginable -- I believe it's 
  2266.  
  2267. /developer/drg/Truetype-Info
  2268.  
  2269. There are a lot of documents in there. Beware! The Word for Windows 
  2270. document is not as up-to-date as the most recent printed version. The 
  2271. WinHelp file appears to be about the same as the printed version. There 
  2272. are problems and errors in the 1.00 version, so be careful.
  2273.  
  2274. --Don
  2275. -- 
  2276. - ----------------------------------------------------
  2277. Don Munsil          | I respect faith, but doubt is
  2278. dmunsil@netcom.com  | what gets you an education.
  2279. don@elseware.com    |                 -- Wilson Mizner
  2280.  
  2281. +++++++++++++++++++++++++++
  2282.  
  2283. >From zune@lysator.liu.se (Andreas Magnusson)
  2284. Date: 29 Apr 1994 10:42:13 GMT
  2285. Organization: (none)
  2286.  
  2287. dmunsil@netcom.com (Don Munsil) writes:
  2288.  
  2289. >Pan Thongvilu (pan@vaxc.cc.monash.edu.au) wrote:
  2290.  
  2291. >It's in about the most un-intuitive place imaginable -- I believe it's 
  2292.  
  2293. >/developer/drg/Truetype-Info
  2294.  
  2295. >There are a lot of documents in there. Beware! The Word for Windows 
  2296. >document is not as up-to-date as the most recent printed version. The 
  2297. >WinHelp file appears to be about the same as the printed version. There 
  2298. >are problems and errors in the 1.00 version, so be careful.
  2299.  
  2300. >--Don
  2301. >-- 
  2302. >------------------------------------------------------
  2303. >Don Munsil          | I respect faith, but doubt is
  2304. >dmunsil@netcom.com  | what gets you an education.
  2305. >don@elseware.com    |                 -- Wilson Mizner
  2306.  
  2307. While we're at it, can somebody tell me if the Apple docs are better, or 
  2308. at least more readable than the Microsoft docs.
  2309. It's a personal taste, but I can't for my life understand the MS-docs. 
  2310. All there are is a listing of all the instructions, and how they supposedly
  2311. work, but no examples or tips or tricks. It's a shame since the Adobe
  2312. docs for Type 1 (which isn't as complex, I know) is full of examples that
  2313. enables me to fully decode, understand and even hand code changes in a font.
  2314. Especially since they say that it's meant to put the intelligence in the
  2315. font instead of in the rasterizer.
  2316.  
  2317. Is there any examples at all available for TrueType? 
  2318.  
  2319. Bye
  2320. /Andreas
  2321. --
  2322. | Andreas Magnusson                  || Vet ni varf|r datavetare {r s}      |
  2323. | Linkoping Institute of Technology  || smarta? Jo, de LISTAR ut allt!      |
  2324. | c89andma@odalix.ida.liu.se         ||      Karin Willborg, C89 LiTH       |
  2325. | zune@nanny.lysator.liu.se          ||(This is in Swedish, it's a bad joke)|
  2326.  
  2327. ---------------------------
  2328.  
  2329. End of C.S.M.P. Digest
  2330. **********************
  2331.  
  2332.  
  2333.